Andrew;
I forgot all about the process tables. Thanks. Interesting though,
systemctl and mod_wsgi both start a root instance and then fork off 3-4
www-data instances. I assume that this is normal. The python manage.py
runserver on the other hand doesn't even show up in the process table. I
suspect it's using the internal development server. Nice to know.
James;
See below
On 11/12/2015 03:24 PM, James Schneider wrote:
On Thu, Nov 12, 2015 at 2:34 PM, Gary Roach <[email protected]
<mailto:[email protected]>> wrote:
Setup for Django development system
OS Debian Linux 8 (jessie) using systemd, not init.d
Python 3.4.2
Django 1.8.5
Apache2 2.4.10 Debian (mmm-worker)
mod_wsgi 4.3.0
Postgresql 9.4.5
Two virtual environments: archive (actual project) and mysite
(django tutorial). Setup done with python3 -m venv <project name>.
There seems to be some variation between this setup and the one
using virtualenv. Confusing.
Somewhat, yes, although both are effectively the same process. You end
up with the same thing either way, though. The 'old' way of installing
the virtualenv packages and then creating the virtualenv with external
shell commands was integrated natively into Python 3 (ie your python3
-m venv command), hence the confusion.
Thanks for the clarification. Between switching between Python 2 and
Python 3, the differences between Debian and systemd vs the other
versions and everyone taking a different approach to the same problem,
us novices get really confused.
pip3 install mod_wsgi in each environment
Run mod_wsgi-express with install-module and setup-server for each.
That's interesting, I've never heard of mod_wsgi-express. From a quick
google though, it appears it should only be used for testing a
mod_wsgi installation, not for production runs. Generally things work
the other way around (Apache configured to use the mod_wsgi module as
it is needed).
Which is exactly where I am at present. I'll fight the production stuff
later.
In /etc/apache2/envvars the following environmental variables are set.
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
In /etc/apache2/apache2.conf the following environmental variables
are used to set user and group.
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
But starting from within the project with mod_wsgi-express
start-server gives:
WARNING: When running as the 'root' user, it is required that the
options '--user' and '--group' be specified to mod_wsgi-express.
Starting with apachectl start or python manage.py runserver give
no errors. Both servers work.
Questions:
What user is apache running as if started with apachectl?
This tends to be distribution specific. Most often it will be www, or
www-data. The serivce user account is generally specified by the
service daemon management system configuration scripts for
Apache/httpd (Systemd in this case).
What user is apache running as if started with python
manage.py runserver?
It isn't. The runserver command is running its own bare-bones web
server that is built into Python/Django (WEBrick IIRC, or at least it
was previously). Only to be used for development, not for production.
Which I discovered to my surprise. See above.
How do I assure that Apache is running as www-data?
Running ps -ef | grep -i '\(apache|http\)' should give you the user
that the processes (Apache and all of its children) are running as in
the first column.
Do I need to start Apache with mod_wsgi-express --user
www-data --group www-data or is python manage.py runserver good
enough?
You should not be using either of those methods for a production
installation of your project. Configure Apache directly to reference
mod_wsgi.
https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/modwsgi/
Answers to these questions would be very very helpful
Gary R
Is there a specific reason that you installed a custom version of
mod_wsgi? Most distributions provide a 2.7 and 3.X compatible version
of mod_wsgi along with their Apache installations (or provide package
installations for mod_wsgi for each respective Python version).
High-end installations with node management and configuration control
tend to use custom compiled versions since they can manage them
effectively. The rest of us peasants are probably better off using the
distribution packages until we figure out what we're doing (myself
included).
Out of curiosity, I logged into one of my Debian 8 boxen and verified
that this is the case:
$ apt-cache search mod-wsgi
libapache2-mod-wsgi - Python WSGI adapter module for Apache
libapache2-mod-wsgi-py3 - Python 3 WSGI adapter module for Apache
$ apt-cache showpkg libapache2-mod-wsgi-py3
Package: libapache2-mod-wsgi-py3
Versions:
4.3.0-1
(/var/lib/apt/lists/mirrors.ocf.berkeley.edu_debian_dists_jessie_main_binary-amd64_Packages)
Description Language:
File:
/var/lib/apt/lists/mirrors.ocf.berkeley.edu_debian_dists_jessie_main_binary-amd64_Packages
MD5: 9804c7965adca269cbc58c4a8eb236d8
Description Language: en
File:
/var/lib/apt/lists/mirrors.ocf.berkeley.edu_debian_dists_jessie_main_i18n_Translation-en
MD5: 9804c7965adca269cbc58c4a8eb236d8
Reverse Depends:
apache2.2-common,libapache2-mod-wsgi-py3 3.4-2
dms-wsgi,libapache2-mod-wsgi-py3
apache2.2-common,libapache2-mod-wsgi-py3 3.4-2
Dependencies:
4.3.0-1 - libc6 (2 2.14) libpython3.4 (2 3.4.2~rc1)
apache2-api-20120211 (0 (null)) python3 (2 3.4) python3 (3 3.5)
libapache2-mod-wsgi (0 (null))
Provides:
4.3.0-1 - httpd-wsgi
Reverse Provides:
Looks like Debian 8 supports your version of Python (3.4.2) for
mod_wsgi out of the box, with no fussing around with Python versions,
etc. It should be no trouble to have it use your existing virtualenv
as well. That would be my recommendation to save yourself a ton of
headache.
-James
Well thats interesting. Guess I'm going to have to go back and back out
some of the software. I really don't think I'm that dumb (getting senile
maybe) but the plethora of information out there gets really confusing
after a bit. I really thank both of you for your help. See you all with
my next problem.
Gary R.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciU_fL8tQETwtnv8Xjdw%3DGa7H9_MMipGq94gdg4M51P4VQ%40mail.gmail.com
<https://groups.google.com/d/msgid/django-users/CA%2Be%2BciU_fL8tQETwtnv8Xjdw%3DGa7H9_MMipGq94gdg4M51P4VQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/564524A5.4050101%40verizon.net.
For more options, visit https://groups.google.com/d/optout.
