I want to get a simple Python "hello world" web page script to run on Windows Vista/ Apache but hit different walls. I'm using WAMP. I've installed mod_python and the module shows, but I'm not quite sure what I'm supposed to do in e.g. http.conf (things like AddHandler mod_python .py either bring me to a file not found, or a forbidden, or module not found errors when accessing http://localhost/myfolder/index.py). I can get mod_python.publisher to work but do I "want" this/ need this?
Can anyone help?
Thanks!
Stay away from mod_python. One common misleading idea is that mod_python is like mod_php, but for python. That is not true. Wsgi is the standard to run python web applications, defined by PEP 333. So use mod_wsgi instead.
Or alternatively, use some web framework that has a server. Cherrypy's one is particulary good. You will be able to run your application both standalone and through mod_wsgi.
An example of Hello World application using cherrypy:
import cherrypy
class HelloWorld(object):
def index(self):
return "Hello World!"
index.exposed = True
application = HelloWorld()
if __name__ == '__main__':
cherrypy.engine.start()
cherrypy.engine.block()
Very easy huh? Running this application directly on python will start a webserver. Configuring mod_wsgi to it will make it run inside apache.
You do not NEED mod_python to run Python code on the web, you could use simple CGI programming to run your python code, with the instructions in the following link: http://www.imladris.com/Scripts/PythonForWindows.html
That should give you some of the configuration options you need to enable Python with CGI, and a google search should give you reams of other info on how to program in it and such.
Mod_python is useful if you want a slightly more "friendly" interface, or more control over the request itself. You can use it to create request filters and other things for the Apache server, and with the publisher handler you get a simpler way of handling webpage requests via python.
The publisher handler works by mapping URLs to Python objects/functions. This means you can define a function named 'foo' in your python file, and any request to http://localhost/foo would call that function automatically. More info here: http://www.modpython.org/live/current/doc-html/hand-pub-alg-trav.html
As for the Apache config to make things work, something like this should serve you well
<Directory /var/www/html/python/>
SetHandler mod_python
PythonHandler mod_python.publisher
PythonDebug On
</Directory>
If you have /var/www/html/ set up as your web server's root and have a file called index.py in the python/ directory in there, then any request to http://localhost/python/foo should call the foo() function in index.py, or fail with a 404 if it doesn't exist.
AddHandler mod_python .py
Have you set 'PythonHandler'?
These days, consider using WSGI instead of native mod-python interfaces for more wide-ranging deployment options. Either through mod-python's WSGI support, or, maybe better, mod-wsgi. (CGI via eg. wsgiref will also work fine and is easy to get set up on a development environment where you don't care about its rubbish performance.)
Related
There's multiple ways, and not clear tutorials or anything online on how to run a fundamentally basic python script with apache.
mod_python? cgi? wsgi?
Does something need to be installed with python?
It's really confusing. I've been working on it for hours.
Flow
Client accesses a web page, say http://example.com/mangojuice (issue 1). Your server (apache) should know mangojuice referes to /etc/www/superhightechjuice/mango.py. Now this python file should be executed (issue 2). Apache should know .py is supposed to be executed and not served plain. But Python does not know when to wakeup and run. So another entity is needed (issue 3).
Solutions to the three issues (interfaces) are handled by mod_wsgi:
WSGI is inherited from the CGI concept (which was used for executing perl scripts and php scripts) to extend to Python scripts (with additional features). mod_wsgi is how Graham Dumpleton implemented it in Apache and is now a standard.
Issue 1 - Conf file which does the mapping - /etc/apache2/conf-available/wsgi.conf
Issue 2 - Install mod_wsgi - during installation, it updates apache configuration files to inform that .py should be executed; along with a host of other things
Issue 3 - Function - application
Code
def application(environ, start_response):
status = '200 OK'
message = b"Hello World" #Prefix b is useful to convert string to bytestring, which is needed by HTTP
response_header = [('Content-type', 'text/html')]
start_response(status, response_header)
return [message]
Reason
When you setup mod_wsgi, it solves issue 1 by having a mapping file wsgi.conf. It solves issue 2 by updating .conf file of apache and also other OS based settings. For Issue 3, it tells apache, I am a middleware whenever I see reference to 'application', I will inform you and you both can talk (Apache and Python). This is how mod_wsgi helps.
Steps to setup mod_wsgi
Install mod_wsgi for Apache2
sudo apt install libapache2-mod-wsgi
Restart Apache to refresh all updates
apachectl restart
Create the mapping file
vi /etc/apache2/conf-available/wsgi.conf
Update the mapping file with url and local path
WSGIScriptAlias /mangojuice /etc/www/superhightechjuice/mango.py
Create the actual code at /etc/www/superhightechjuice/mango.py
Code sample same as mentioned above. start_response tells mod_wsgi that requests are incoming. mod_wsgi talks with Apache and lets your code through.
Reference:
Official mod_wsgi documentation
I have Django installed on a corporate intranet, running on Apache using mod_wsgi. The Apache server has SSL set up, and everything is working as expected when users hit CGI pages, but my django applications don't seem to be picking up any SSL related environment variables (ssl_client_s_dn, etc) whether they go to my django pages with http:// or https://.
I think the main issue is that I don't understand where django is pulling it's os.environ from, and how to change that. I've looked through the official django documentation and other posts on 'django' and 'ssl', but those seem to deal with views that need to sometimes be http, and sometimes https. I am just trying to get ssl related information to show up in os.environ at all, and I don't know where to look next.
What do you need to know? httpd.conf wsgi configuration settings? My projects settings.py, or lines in wsgi.py?
Any help is much appreciated.
If you are using mod_wsgi within Apache, and you set the environment variables in Apache (using SetEnv), then you are out of luck: mod_wsgi's environment variables are separate from these in Apache.
Many people are running into similar problems, when setting variable in Apache using SetEnv is completely invisible when trying to access os.environ in Django.
There is however some solution. It is listed here, and basically comes to these lines in your wsgi script (adjusted to your needs):
def application(environ, start_response):
os.environ['ssl_client_s_dn'] = environ['ssl_client_s_dn']
return _application(environ, start_response)
Which basically translates first argument of your WSGI application into os.environ dictionary. For details see the post linked above.
I am trying to use cherrypy virtualhost dispatcher for serving multiple different applications.
My idea was to have separate configuration file for each application, but I am kinda lost.
If I use virtualhost dispatcher, all applications are in same namespace, so for example section for database connection can occur only once. Or not? Can you please help?
For my current purposes, I am satisfied with this solution:
I create separate config file for a cherrypy application and I am using the same class as cherrypy for parsing the file.
from cherrypy.lib.reprconf import Config
settings = Config(os.path.join(confPath, "settings.cfg"))
Also, there is python standard module for handling config files named configparser.
This question is also quite irrelevant for me, because serving multiple cherrypy applications (as I thought about it) is quite difficult with cherrypy server. I decided to use cherrypy as WSGI server behind appache and this solves the problem explicitly.
I have a Bluehost account where I can run Python scripts as CGI. I guess it's the simplest CGI, because to run I have to define the following in .htaccess:
Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py
Now, whenever I look up web programming with Python, I hear a lot about WSGI and how most frameworks use it. But I just don't understand how it all fits together, especially when my web server is given (Apache running at a host's machine) and not something I can really play with (except defining .htaccess commands).
How are WSGI, CGI, and the frameworks all connected? What do I need to know, install, and do if I want to run a web framework (say web.py or CherryPy) on my basic CGI configuration? How to install WSGI support?
How WSGI, CGI, and the frameworks are all connected?
Apache listens on port 80. It gets an HTTP request. It parses the request to find a way to respond. Apache has a LOT of choices for responding. One way to respond is to use CGI to run a script. Another way to respond is to simply serve a file.
In the case of CGI, Apache prepares an environment and invokes the script through the CGI protocol. This is a standard Unix Fork/Exec situation -- the CGI subprocess inherits an OS environment including the socket and stdout. The CGI subprocess writes a response, which goes back to Apache; Apache sends this response to the browser.
CGI is primitive and annoying. Mostly because it forks a subprocess for every request, and subprocess must exit or close stdout and stderr to signify end of response.
WSGI is an interface that is based on the CGI design pattern. It is not necessarily CGI -- it does not have to fork a subprocess for each request. It can be CGI, but it doesn't have to be.
WSGI adds to the CGI design pattern in several important ways. It parses the HTTP Request Headers for you and adds these to the environment. It supplies any POST-oriented input as a file-like object in the environment. It also provides you a function that will formulate the response, saving you from a lot of formatting details.
What do I need to know / install / do if I want to run a web framework (say web.py or cherrypy) on my basic CGI configuration?
Recall that forking a subprocess is expensive. There are two ways to work around this.
Embedded mod_wsgi or mod_python embeds Python inside Apache; no process is forked. Apache runs the Django application directly.
Daemon mod_wsgi or mod_fastcgi allows Apache to interact with a separate daemon (or "long-running process"), using the WSGI protocol. You start your long-running Django process, then you configure Apache's mod_fastcgi to communicate with this process.
Note that mod_wsgi can work in either mode: embedded or daemon.
When you read up on mod_fastcgi, you'll see that Django uses flup to create a WSGI-compatible interface from the information provided by mod_fastcgi. The pipeline works like this.
Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)
Django has several "django.core.handlers" for the various interfaces.
For mod_fastcgi, Django provides a manage.py runfcgi that integrates FLUP and the handler.
For mod_wsgi, there's a core handler for this.
How to install WSGI support?
Follow these instructions.
https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithDjango.wiki
For background see this
http://docs.djangoproject.com/en/dev/howto/deployment/#howto-deployment-index
I think Florian's answer answers the part of your question about "what is WSGI", especially if you read the PEP.
As for the questions you pose towards the end:
WSGI, CGI, FastCGI etc. are all protocols for a web server to run code, and deliver the dynamic content that is produced. Compare this to static web serving, where a plain HTML file is basically delivered as is to the client.
CGI, FastCGI and SCGI are language agnostic. You can write CGI scripts in Perl, Python, C, bash, whatever. CGI defines which executable will be called, based on the URL, and how it will be called: the arguments and environment. It also defines how the return value should be passed back to the web server once your executable is finished. The variations are basically optimisations to be able to handle more requests, reduce latency and so on; the basic concept is the same.
WSGI is Python only. Rather than a language agnostic protocol, a standard function signature is defined:
def simple_app(environ, start_response):
"""Simplest possible application object"""
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['Hello world!\n']
That is a complete (if limited) WSGI application. A web server with WSGI support (such as Apache with mod_wsgi) can invoke this function whenever a request arrives.
The reason this is so great is that we can avoid the messy step of converting from a HTTP GET/POST to CGI to Python, and back again on the way out. It's a much more direct, clean and efficient linkage.
It also makes it much easier to have long-running frameworks running behind web servers, if all that needs to be done for a request is a function call. With plain CGI, you'd have to start your whole framework up for each individual request.
To have WSGI support, you'll need to have installed a WSGI module (like mod_wsgi), or use a web server with WSGI baked in (like CherryPy). If neither of those are possible, you could use the CGI-WSGI bridge given in the PEP.
You can run WSGI over CGI as Pep333 demonstrates as an example. However every time there is a request a new Python interpreter is started and the whole context (database connections, etc.) needs to be build which all take time.
The best if you want to run WSGI would be if your host would install mod_wsgi and made an appropriate configuration to defer control to an application of yours.
Flup is another way to run with WSGI for any webserver that can speak FCGI, SCGI or AJP. From my experience only FCGI really works, and it can be used in Apache either via mod_fastcgi or if you can run a separate Python daemon with mod_proxy_fcgi.
WSGI is a protocol much like CGI, which defines a set of rules how webserver and Python code can interact, it is defined as Pep333. It makes it possible that many different webservers can use many different frameworks and applications using the same application protocol. This is very beneficial and makes it so useful.
If you are unclear on all the terms in this space, and lets face it, its a confusing acronym-laden one, there's also a good background reader in the form of an official python HOWTO which discusses CGI vs. FastCGI vs. WSGI and so on: http://docs.python.org/howto/webservers.html
It's a simple abstraction layer for Python, akin to what the Servlet spec is for Java. Whereas CGI is really low level and just dumps stuff into the process environment and standard in/out, the above two specs model the http request and response as constructs in the language. My impression however is that in Python folks have not quite settled on de-facto implementations so you have a mix of reference implementations, and other utility-type libraries that provide other things along with WSGI support (e.g. Paste). Of course I could be wrong, I'm a newcomer to Python. The "web scripting" community is coming at the problem from a different direction (shared hosting, CGI legacy, privilege separation concerns) than Java folks had the luxury of starting with (running a single enterprise container in a dedicated environment against statically compiled and deployed code).
I tried to follow a couple of googled up tutorials on setting up mod_python, but failed every time. Do you have a good, step-by step, rock-solid howto?
My dev box is OS X, production - Centos.
There are two main ways of running Python on Apache. The simplest would be to use CGI and write normal Python scripts while the second is using a web framework like Django or Pylons.
Using CGI is straightforward. Make sure your Apache config file has a cgi-bin set up. If not, follow their documentation (http://httpd.apache.org/docs/2.0/howto/cgi.html). At that point all you need to do is place your Python scripts in the cgi-bin directory and the standard output will become the HTTP response. Refer to Python's documentation for further info (https://docs.python.org/library/cgi.html).
If you want to use a web framework you'll need to setup mod_python or FastCGI. These steps are dependent on which framework you want to use. Django provides clear instructions on how to setup mod_python and Django with Apache (http://www.djangoproject.com/documentation/modpython/)
Yes, mod_python is pretty confusing to set up. Here's how I did it.
In httpd.conf:
LoadModule python_module modules/mod_python.so
<Directory "/serverbase/htdocs/myapp">
AddHandler mod_python .py
PythonHandler myapp
PythonDebug On
and in your application directory:
$ /serverbase/htdocs/myapp$ ls -l
total 16
-r-xr-xr-x 1 root sys 6484 May 21 15:54 myapp.py
Repeat the configuration for each python program you wish to have running under mod_python.
Are you running Python on UNIX or Windows?
An alternative to mod_python and FastCGI is mod_wsgi. You can find out more at modwsgi
I have built and installed this on Solaris without problems. I had previously tried mod_python but ran into problems with shared libraries as part of the build. There are good install docs available.
The problem for me wasn't in Apache set up, but in understanding how mod_apache actually uses the .py files. Module-level statements (including those in a if __name__=='__main__' section) are not executed--I assumed that the stdout from running the script at the commandline would be what the server would output, but that's not how it works.
Instead, I wrote a module-level function called index(), and had it return as a string the HTML of the page. It's also possible to have other module-level functions (e.g., otherFunction()) that can be accessed as further segments in the URI (e.g., testScript/otherFunction for the file testScript.py.)
Obviously, this makes more sense than my original stdout conception. Better capability of actually using Python as a scripting language and not a humongous markup language.