I have seen a lot of similar questions, but still i am failing. I have win XP, Apache 2.2, Django 1.4, Python 2.7 and mod_wsgi 3.3. All i am trying to do is when you hit the page the bat file executes and which echoes hi. This works when i run it on the django internal dev server. But when i got to Apache, it fails and in the error.log i get the message
The system cannot write to the specified device.
The system cannot write to the specified device.
The system cannot write to the specified device.
The system cannot write to the specified device.
The system cannot write to the specified device.
I have not seen that error in many other places. Most people seem to get "Permission denied". I still think the permissions are wrong. So when i run it is the django internal server i get in the console:
Validating models...
0 errors found
Django version 1.4, using settings 'testsite.settings'
Development server is running at http:`//127.0.0.1:8000/
Quit the server with CTRL-BREAK.
C:\Sites\cprm>echo hi
hi
[18/Sep/2012 14:58:45] "GET / HTTP/1.1" 200 63
That seems fine. The only thing throwing me off that I'm running from /testsite and not /cprm. I could just cd .. before. Anyway, so since in the internal server it is writing to the console, i guess i need to do the equivalent in apache. I'm not sure where the apache console is. I tried adding permission to the apache log file as that is where the error gets generated. I'm not sure that is equivalent to the regular console.
My Apache file looks like this (ignore back ticks):
<`VirtualHost *>
ServerName http://example.com:80
WSGIScriptAlias /cprm "C:/sites/cprm/wsgi.py"
WSGIScriptAlias /testsite "C:/sites/testsite/wsgi.py"
<Directory "C:/sites">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
<Directory "C:/Program Files/Apache Software Foundation/Apache2.2/logs">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
<`/VirtualHost>
My view just looks like this:
from django.http import HttpResponse
import datetime, os
def home(request):
os.system('C:/Sites/testsite/testsite/test.bat')
now = datetime.datetime.now()
html = "<html><body>It is now %s.</body></html>" % now
return HttpResponse(html)
It's basically just a quick test I tried doing.
EDIT
Hi pacha. Thanks for the response. I have done some reading on the topic now. So I made the changes you indicated. My wsgi.py file looks like such:
import os, sys
path = 'C:/Sites/testsite'
if path not in sys.path:
sys.path.append(path)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "testsite.settings")
sys.stdout = sys.stderr
print 'hi'
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
Then when i go to error.log, i do in fact see 'hi' printed. So that is good. However, the test.bat file w/ the echo hello does not execute and i still get the same message. And thanks for the permission advice. I am now no longer using virtual. I am not ready for that yet. Any other ideas for what I could try?
Things to check
Permissions what are the user permissions on the file
C:/Sites/testsite/testsite/test.bat?
Are they read for the same user that is running the Apache Process?
Have you installed python for all logged in users not just for?
Have you reviewed your Apache conf directives?
User/Group: The name (or #number) of the user/group to run httpd as.
It is usually good practice to create a dedicated user and group for
running httpd, as with most system services.
User carlos
Group Administrators
Does that same user have permissions to read the file on the file system?
<Directory "C:/Sites/testsite/testsite/">
AllowOverride None
Options None
Order deny,allow
Allow from all
</Directory>
Your problem seems to be related to how the standard output is handled. WSGI disables standard output by default. That's why your program works fine in the development server (which redirects the output to the terminal where the server was launched) but doesn't work with Apache.
You can enable stdout in WSGI using a configuration directive that you put in your virtual host conf file (together with the other WSGI directives):
WSGIRestrictStdout Off
However, take into account that Apache isn't associated to any terminal. If you want to see the output of your program then one thing you can do is to redirect the standard output to the standard error stream by adding this to your WSGI file:
sys.stdout = sys.stderr
Restart Apache an you should see any output of your application (or any child process, as it is your case) in the error.log file of Apache.
Note: Don't add the Apache log files directory to your virtual host configuration. You aren't granting permissions to Apache over those files but allowing anyone to see them, which is as you can imagine a non-trivial security risk.
Update
Avoiding permission problems
You may want to try to use WSGI in daemon mode. That way the web application can be executed under your username (much like when using the internal development server). In your case, the configuration directives should be something along the lines:
WSGIDaemonProcess site1 user=<USERNAME> group=<GROUP> processes=1 threads=1
WSGIScriptAlias /testsite "C:/sites/testsite/wsgi.py"
<Directory "C:/sites/testsite/">
WSGIProcessGroup site1
WSGIApplicationGroup %{GLOBAL}
Order allow,deny
Allow from all
</Directory>
You have to substitute <USERNAME> and <GROUP> by your username and group in your Windows machine (it may work by just setting the username though). This is usually a nice way of avoiding permission issues since your application will be executed in a very similar way to how it is executed by the development server. (Notice that we're using just one process and one thread just to make Apache behave even more closely to how the development server does. You surely want to change those values in production to higher values).
You can check the daemon mode documentation here
Executing your script
To call external program from Python code, the module subprocess is usually preferred over os.system calls. The former allows you to have much more control over how the new process has to be executed whereas the later just passes the call to the operating system.
You can try the subprocess.check_output function. It executes a script/program and allows you to capture its output:
print subprocess.check_output(['C:\Sites\testsite\testsite\test.bat'], shell=True)
It has the additional advantage that you can capture the output in a string variable. (Btw, you may or may not need the shell=True param in Windows when calling a bat script, I'm not sure about that).
Related
I am trying to run django on XAMPP Apache server and followed the steps mentioned here. Here are the changes in Apache config:[![enter image description here][1]][1]
When access the application in browser below is the result instead of django page:
[![enter image description here][2]][2]
Please help what I am missing in this ?
#Razenstein: Following are errors in Apache log:
AH02102: C:/xampp/htdocs/polls/mysite/mysite/wsgi.py is not executable; ensure interpreted scripts have "#!" or "'!" first line (9)Bad file descriptor: [client 127.0.0.1:58357] AH01222: don't know how to spawn child process: C:/xampp/htdocs/polls/mysite/mysite/wsgi.py
The application is running fine with built in python server. After correcting Alias getting "500 | Internal Server Error"
[1]: https://i.stack.imgur.com/w2R0Y.png
[2]: https://i.stack.imgur.com/vl8Da.png
ok, this error message says that Apache tries to execute wsgi.py as a cgi script and not as python. A possible reason is, that you tried to deploy your app on Apache with some wrong commands that are still in the httpd.conf or vhosts-httpd.conf. This typically happens if you follow one (bad?) tutorial without success, switch to another one and forgot to clean the the code from the first trial (only a guess!). There is all kinds of strange turorials out there and sometimes it is also difficult to understand if they are for Windows or Unix.
Something like the follwing would cause that behavior:
Alias / C:/xampp/htdocs/polls/mysite/mysite/wsgi.py
<Directory C:/xampp/htdocs/polls/mysite/mysite>
Options +ExecCGI
AddHandler cgi-script .cgi .pl .asp .py
Require all granted
</Directory>
please search in your httpd.conf and vhosts-httpd.conf if you have left something similar.
your "WSGIScriptAlias ...." is overwritten by that and not active.
I'm tying to setup Apache/2.2.22 (Debian) mod_wsgi/3.3 Python/2.7.3
I manage to get the WSGIScriptAlias executed, but only the top level module code, not the application defined therein.
Apache configuration:
LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so
WSGIScriptAlias /testurl /home/django/test/test/wsgi_test.py
<Directory /home/django/test/test>
<Files wsgi_test.py>
Order deny,allow
Allow from all
</Files>
</Directory>
wsgi_test.py:
#!/usr/bin/python
import sys
print >> sys.stderr, "I'm wsgi_test"
def application(environ, start_response):
print >> sys.stderr, 'in application'
status = '200 OK'
output = 'hello World'
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
When requesting the url using a browser the wsgi_test.py script gets executed ("I'm wsgi_test" appearing in the apache error log). However, no page is served (500 internal server error) and there is an additional error log entry Premature end of script headers: wsgi_test.py.
As a second test, I used a simple script, which correctly serves 'Hello World':
wsgi_test2.py:
#!/usr/bin/python
import sys
print 'Content-type: text/plain\n\n'
print 'Hello World'
My question:
How does mod_wsgi know and execute the application?
From the above tests, I conclude that wsgi_test.py is immediately executed. Since there is no executable code but only a definition of application, the script does not output anything and thus the server complains about the missing html headers. How do I tell the system to run the application?
The mod_wsgi module does not execute the script in the way that you are likely thinking. That is, it doesn't run them as a program.
Your Apache configuration is likely setup so that files with .py extension are being executed as a CGI script and so this is not actually being handled by mod_wsgi. This would explain the behaviour you are seeing.
Either disable AddHandler directive which makes .py files CGI scripts, or rename your WSGI scripts to have a .wsgi extension and change the WSGIScriptAlias directive to match.
When this is done, then mod_wsgi will load the WSGI script into memory and then run the Python code in the memory of the server processes. So not as a separate program execution.
If you ensure that the LogLevel directive in Apache is set to info if currently set to warn, then you should see a lot more messages logged by mod_wsgi about when it is loading the WSGI script to run it the first time. This will confirm that mod_wsgi is handling them.
I am trying to run to apache bloodhound tracker on apache2 web server. I am using 0.7 version of the blood hound. I followed the website https://issues.apache.org/bloodhound/wiki/BloodhoundInstall
Blood hound is running on port 8000.
But the problem is I am not able to run the blood hound on port 80, so that if I hit bloodhound.mydomain.com, I should get bloodhound. I have mentioned my apache2 webserver setting file as specified in the website
/etc/apache2/sites-available/bloodhound
<VirtualHost *:8080>
WSGIDaemonProcess bh_tracker user=ubuntu python-path=/home/ubuntu/bloodhound-0.7/installer/bloodhound/lib/python2.7/site-packages
WSGIScriptAlias /bloodhound /home/ubuntu/bloodhound-0.7/installer/bloodhound/site/cgi-bin/trac.wsgi
<Directory /home/ubuntu/bloodhound-0.7/installer/bloodhound/site/cgi-bin>
WSGIProcessGroup bh_tracker
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
<LocationMatch "/bloodhound/[^/]+/login">
AuthType Digest
AuthName "ubuntu"
AuthDigestDomain /bloodhound
AuthUserFile /home/ubuntu/bloodhound-0.7/installer/bloodhound/environments/main/bloodhound.htdigest
Require valid-user
</LocationMatch>
</VirtualHost>
After adding the above file, its not running on either of the ports 8000 and also 8080 also.
How do I make it run. Kindly help me. By the way I am using ubuntu ec2 instance.
By golly I think I've figured it out! I've been stuck right about where you are on my own Bloodhound port configuration for days.
n3storm is correct: the whole magic of setting up mod_wsgi is that you no longer need to manually start bloodhound with that
tracd port=8080 /ridiculously/long/path/to/bloodhound/installer/bloodhound/environments/main
command. Instead, mod_wsgi runs all that python for you the moment your web browser requests http://[host]:8080/bloodhound, meaning your Bloodhound server is ready to serve the moment it's turned on.
The pain is how many interlocking config files are involved, and how many tiny things can break down the whole process. I don't really know python, I just barely understand Apache, and I'm 70% confident I've accidentally opened some gaping security that I don't understand, but here's my understanding of the mod_wsgi + Apache + Bloodhound domino chain. Paths are for my Apache 2.4 installation on Ubuntu 14.04.1 LTS:
1. You load http://[host]:8080/bloodhound
For this to work, I needed to edit /etc/apache2/ports.conf so that Apache is actually listening on port 8080. So add the line
Listen 8080
to /etc/apache2/ports.conf
Now visiting http://[host]:8080/bloodhound should at least show you something from Apache. For me, it was a HTTP Error 403: Forbidden page, and next up is my home remedy for the Error 403 blues!
2. Apache triggers bloodhound.conf
FULL PATH: /etc/apache2/sites-available/bloodhound.conf
Technically, Apache is looking in /etc/apache2/sites-enabled/ for a matching VirtualHost rule but you set this up by creating/editing .conf files in /sites-availabe/ and then activating them with the Apache command
a2ensite [sitename].conf
So. Apparently, Apache 2.4 changed its access control syntax for .conf files. So, to stop the Error 403ing, I changed
Order deny,allow
Allow from all
in /etc/apache2/sites-available/bloodhound.conf to
Require all granted
And then once again you should restart Apache with
sudo apachectl graceful
or
sudo /etc/init.d/apache2 graceful
or maybe
sudo service apache2 restart
I'm not sure, they all seem to work equally but I suppose the graceful ones are nice because they don't shut down your server or something important like that.
3. bloodhound.conf triggers trac.wsgi
FULL PATH: /ridiculously/long/path/to/bloodhound/installer/bloodhound/site/cgi-bin/trac.wsgi
After figuring out that ton of other things, I realized that, in the end, the default script that Bloodhound generates worked fine for me:
import os
def application(environ, start_request):
if not 'trac.env_parent_dir' in environ:
environ.setdefault('trac.env_path', '/usr/local/bloodhound/installer/bloodhound/environments/main')
if 'PYTHON_EGG_CACHE' in environ:
os.environ['PYTHON_EGG_CACHE'] = environ['PYTHON_EGG_CACHE']
elif 'trac.env_path' in environ:
os.environ['PYTHON_EGG_CACHE'] = \
os.path.join(environ['trac.env_path'], '.egg-cache')
elif 'trac.env_parent_dir' in environ:
os.environ['PYTHON_EGG_CACHE'] = \
os.path.join(environ['trac.env_parent_dir'], '.egg-cache')
from trac.web.main import dispatch_request
return dispatch_request(environ, start_request)
4. trac.wsgi serves up the HTML files for Bloodhound
Isn't the internet just magical?
By using Apache mod_wsgi you don't need Bloodhound running apart anymore. Is mod_wsgi what makes Bloodhound running. You should use standard apache port in this case.
Also, I guess you should use a ServerName directive at Virtualhost (or is it you only serve one host?)
I installed WAMP and ColdFusion but when I go to http://localhost/cfide/administrator it gives a 404 error. CFML is displayed fine so the ColdFusion server must be running correctly.
I'm using WAMP ServerVersion 2.2 ColdFusion 9 and Windows 7 64bit.
Both Seybsen and Jason hit on the two most common reasons for not being able to hit the administrator. Seeing as you're on Windows, it's unlikely to be case-sensitivity. But not having index.cfm as a default document will be a problem. You can add it to the http.conf:
<IfModule dir_module>
DirectoryIndex dex index.html index.cfm default.cfm
</IfModule>
If hitting the entire string including index.cfm doesn't work, then it's likely Mark's solution. To elaborate, you'll need to check either the http.conf or the mod_jk.conf to make sure that the alias is there:
Alias /CFIDE "C:\[full path to CFIDE]\CFIDE"
<Directory "C:\[full path to CFIDE]\CFIDE">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
That alias should work for all virtual hosts as well.
Check your httpd.conf file to make sure there is an alias for CFIDE (and remember it's case sensitive). If you still can't make it work try running the connector script for apache found in cfusion9/bin ... or run wsconfig for a gui to try to hook it up. Also remember to run as administrator.
Try your actual ipaddress incase your server settings have not setup localhost by default.
In windows - run CMD or Command Prompt...
Then ipconfig
U should get ur ipaddress...
Replace localhost with that IP address - I have had that problem in the past...
And then create a shortcut with proper address
Apache & mod_wsgi are configured correctly (I've created a hello
world .html apache file and a hello world mod_wsgi application with
no problems). I now need my Django app to work with my django.wsgi
file. What makes me think that it's not recognizing my wsgi file is that I
went into my django.wsgi file I created and completely deleted all of
the code in the file and restarted Apache and it still gives me the
same page (a listing of the files from Django app, not my actual
Django application. Configuring Apache and mod_wsgi went really well
but I'm at a loss of how to fix this. Here are some details:
Here is my current django.wsgi file:
import os
import sys
sys.path.append('/srv/www/duckling.org/store/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'store.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
I've tried a few different versions of the django.wsgi file
(including a version like the one over at http://www.djangoproject.com/).
This version of my wsgi is from here:
http://library.linode.com/frameworks/django-apache-mod-wsgi/ubuntu-10...
Also, here is my vhost apache configuration file below. I think these
are the main files that are suppose to do the job for me. Let me know if
you see any errors in what I'm doing and what else I might do to fix
this. The django app runs fine on the django's built-in development
server so I'm thinking it might have something with my paths.
No errors in my apache error.log file as well. It's acting as there's
no problem at all, which is not the case...the project isn't loading,
like I said just a listing of my files and directories of my Django
project. Here is my apache config file:
<VirtualHost 1.2.3.4:80>
ServerAdmin hi#duckling.org
ServerName duckling.org
ServerAlias www.duckling.org
DocumentRoot /srv/www/duckling.org/store/
<Directory /srv/www/duckling.org/store/>
Order Allow,Deny
Allow from all
</Directory>
Alias /static/ /srv/www/duckling.org/store/static/
<Directory /srv/www/duckling.org/store/static>
Order deny,allow
Allow from all
</Directory>
WSGIScriptAlias store/ /srv/www/duckling.org/store/wsgi-scripts/django.wsgi
<Directory /srv/www/wsgi-scripts>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
And here are versions of the stack that I'm using, I saw over at the
mod_wsgi site that you all would like the versions of what I'm using
on the server:
Apache/2.2.14 (Ubuntu) PHP/5.3.2-1ubuntu4.5 with Suhosin-Patch
mod_python/3.3.1 Python/2.6.5 mod_wsgi/2.8
thanks,
j.
For a start, you should definitely not keep your Django files under your DocumentRoot. There's no need for them to be there, and it's a potential security risk - as you've seen, your current misconfiguration allows Apache to serve up your files directly: an attacker could guess that and download your settings.py, complete with your database password.
So, get rid of that DocumentRoot directive completely, as well as the first Directory section which allows direct access to /srv/www/duckling.org/store/. (You probably don't need the one serving up /srv/www/wsgi-scripts either.) That should make things a bit better.
By the way, this configuration will serve your website under duckling.org/store - is that what you want? If you want it under the root, you should just use:
WSGIScriptAlias / /srv/www/duckling.org/store/wsgi-scripts/django.wsgi