On 08/11/2014, at 1:21 AM, Jon Flash <[email protected]> wrote:
> I am using 'mod_wsgi' express version with my Django application(s). I was
> wondering if there is any documentation for the 'mod_wsgi.server'
> INSTALLED_APP.
What in particular are you wanting to know about it?
The 'mod_wsgi.server' package is only available if you have done a pip install
of 'mod_wsgi' and so installed the mod_wsgi-express script as well.
The mod_wsgi.server package mainly exists to support mod_wsgi-express and so
also the runmodwsgi management command for Django manage.py when
'mod_wsgi.server' is listed in the installed applications as it uses the same
underlying mechanism to configure and launch Apache. The latter works by
'mod_wsgi.server' package having a 'management' sub package which Django looks
for management commands to extend what is available for manage.py.
There is only minimal documentation for mod_wsgi-express at this point and it
can be found at:
https://pypi.python.org/pypi/mod_wsgi
You can also find descriptions of each command line option to 'start-server' of
mod_wsgi-express by running:
mod_wsgi-express start-server --help
Documentation is lacking right now as I am treating mod_wsgi-express as a bit
of a fun project to get myself interested in working on mod_wsgi again after
having neglected it for quite some time. Granted I haven't said much publicly
about mod_wsgi-express, there also hasn't been a great deal of interest in it
yet either to make me feel motivated to focus on the documentation.
> Also what are the downsides to using mod_wsgi express in production vs the
> traditional mod_wsgi / Apache installation.
The main downside is that how mod_wsgi-express is installed and how it is used
will upset system administrators who are overly paranoid and only trust binary
packages that come with their operating system. They will also be upset because
they are taken out of the loop as far as having to configure Apache themselves,
so they will feel that they are loosing a measure of control and so will push
back on any desire to use it.
Personally I would argue this actually can be a good thing.
The first reason why is that binary packages for the Linux distributions are
generally woeful out of date. Most of the popular Linux distributions still
only ship with mod_wsgi version 3.3 or 3.4 where as the latest version is
4.3.2. So they are more than 16 releases behind.
Their argument in using binary packages from the Linux distribution is that
they are supported if a LTS release of that Linux variant. That is actually
mostly a load of nonsense as I don't personally actively maintain older
mod_wsgi versions and the Linux distributions certainly don't. The versions
they ship therefore carry bugs which could cause you problems and deny you from
using features in newer versions which could make your life easier.
But then they will say that the older versions will get security updates. That
also is not entirely true. They may get a security fix, but that will only
occur if a CERT advisory has been raised and a fix can even be back ported.
Even if a CERT advisory is raised, for third party packages like mod_wsgi I
know from experience that Linux distributions can take up to 6 months to get
around to actually updating the binary package.
So the idea that binary packages are somehow better in some way because of a
quick turn around on security fixes is a bit of a fallacy. This may be true for
main line core packages, but for third party packages they get very little love
and you can actually be putting yourself in a bad position by not building the
latest from source code yourself.
The second reason is I see too many Apache configurations which are done quite
badly. You will see some where people feel that the defaults are no good and
start over with an empty config believing they can do better. In doing that
though, they immediately throw away some of the security that the defaults
provide. Even when people retain the default Apache configuration, that
defaults are always tailored to static or PHP sites and so the performance for
a Python web site can be quite bad as a result and a lot more resources used up
than need be if things were setup right for a Python web site.
So mod_wsgi-express rather than having downsides, is actually meant to improve
on the sad state of affairs that can quite often exist.
The idea with mod_wsgi-express is that through my experience of Apache and what
makes a good configuration for Python web hosting, I can generate the
configuration automatically for you. This approach will probably work for a
good majority of people who are running a Python web site. It will not work for
everyone though, especially where an Apache instances is shared for other
purposes, and in those cases you would still have to fall back to configuring
an existing Apache installation yourself.
Overall the aim of mod_wsgi-express is to provide a minimal amount of options
which will satisfy the needs of 90% of the people out there. This is in
contrast to some other WSGI hosting solutions where 90% of the options are
totally irrelevant and just make it hard to find what you do need.
This is not to say that everything is in place to make it as easy as possible
to use mod_wsgi-express. One thing that still needs to be done is the automatic
generation of system start scripts which could then be quickly integrated into
a Linux system to get things running. Due to my lack of knowledge of different
Linux systems this is where I will need some help, but although I put a call
out a while ago for help in this area, I got no responses. That is therefore
something which will come only slowly at this point as I want to focus on other
areas for the time being.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" 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/modwsgi.
For more options, visit https://groups.google.com/d/optout.
