Ι have developed a Django project and uploaded it to a cloud VΜ. Currently i have access to it through 8080 port.
python manage.py runserver 0.0.0.0:8080
If i enter the url without the 8080 port, it shows the "it works" page. How can i set my Django project to run by default on 80 port?
I am using Ubuntu 12.04 server
As docs say, runserver isn't meant as a deployment server. It also mentions that you probably can't start it on port 80 unless you run it as root.
Here is the kind of file you will need to put in /etc/apache2/sites-enabled, you need to adjust the paths in it. You also need to load mod_wsgi which you can do via apt-get.
<VirtualHost 192.168.1.14:80>
ServerAdmin youremail#whatever.com
ServerName www.whatever.com
ServerAlias whatever.com
Alias /robots.txt /home/dimitris/Python/mysite/site_media/robots.txt
Alias /favicon.ico /home/dimitris/Python/mysite/site_media/favicon.png
Alias /static/ /home/dimitris/Python/mysite/site_media/static
WSGIDaemonProcess mysite user=dimitris processes=1 threads=5
WSGIProcessGroup mysite
WSGIScriptAlias / /home/dimitris/Python/mysite/deploy/mysqite_wsgi.py
# Possible values include: debug, info, notice, warn, error, crit, alert, emerg.
LogLevel debug
ErrorLog ${APACHE_LOG_DIR}/mysite.error.log
CustomLog ${APACHE_LOG_DIR}/mysite.access.log combined
ServerSignature Off
</VirtualHost>
Most of this assumes you are running in a virtualenv, that means you will need a wsgi file to get things running. The above file sets up apache to run your "wsgi" file which looks something like this:
import os
from os.path import abspath, dirname, join
import sys
with open("/tmp/mysite.sys.path", "w") as f:
for i in sys.path:
f.write(i+"\n")
#redirect sys.stdout to sys.stderr for libraries that use
#print statements for optional import exceptions.
sys.stdout = sys.stderr
sys.path.insert(0, abspath(join(dirname(__file__), "../../")))
sys.path.insert(0, abspath(join(dirname(__file__), "../../lib/python2.7/site-packages/")))
from django.conf import settings
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
mod_wsgi, then opens this one file and executes it. application is the part that waits for requests from the webserver, and the rest behaves just like runserver except it can be multi-process and multi-threaded.
In the terminal while in a virtual environment, run:
sudo ./manage.py runserver 80
You will be asked for your password and it will run the server on port 80.
Related
I have a small web application that I have built using Flask and python. With the internal server that I used for developing everything runs fine. However now I want to use apache to start using it. But it doesn`t work. Keep in mind that I have never worked with apache or web based stuff before.
I used this guide as my starting point:
http://flask.pocoo.org/docs/deploying/mod_wsgi/
right now I have my application which is in the file called "/rg/server.py" and looks like this:
app=Flask(__name__)
# all app routes...
if __name__ == '__main__':
app.run(
debug=True,
host="127.0.0.1",
port=80
)
than I have a wsgi file as "/rg/wsgi/minerva.wsgi"
import sys
sys.path.insert(0, /rg)
from server import app as minerva
and finally I have an apache config file in "etc/apach2/sites-available/minerva.com":
<VirtualHost *>
ServerName minerva.test
WSGIDaemonProcess minerva threads=10
WSGIScriptAlias / /rg/wsgi/minerva.wsgi
<Directory /rg>
WSGIProcessGroup minerva
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
Then I updated apache with a2ensite minerva.com which succeded. Then I releaded Apache and no errors. However I cannot acces minerva.test in any way...
If I type in apache2ctl -S it does list minerva.test
I have no idea what is going wrong...
system information:
OS: debian 64bit
python 2.7
The WSGI application entry point must be called 'application' for mod_wsgi. You have:
from server import app as minerva
It should be:
from server import app as application
You aren't even getting that far though, else the line:
sys.path.insert(0, /rg)
would give a syntax error.
Going back further, instead of:
<VirtualHost *>
you should have:
<VirtualHost *:80>
and finally, if 'minerva.test' isn't actually a resolvable host, you will not get anywhere.
So fill out your question with the actual URL you are using in the browser and also indicate whether 'minerva.test' is even listed in local hosts file.
The first thing I would check would be to make sure mod_wsgi is installed and loaded by apache. If that's fine, your setup looks pretty similar to mine with a few minor differences:
I had to add WSGISocketPrefix /var/run/wsgi above my VirtualHost definitoin. See here.
I included user and group values on the WSGIDaemonProcess line.
I am running Ubuntu 14.04 on my notebook and I am using Django 1.6.4 (with virtualenv) together with Apache 2.4.7.
I would like to access two django projects through my local apache. Therefore, theses projects are called kleyboldt (name of a guy I am writing for) and kleyboldt2. Normally I store my web projects under /home/nick/Workspace/Web. After watching tutorial I ended up with two domains pointing to the same django project. To be sure I rewrote the config and placed my projects under /var/www.
At the beginning I wrote two files in order to configure apache.
/etc/apache/sites-available/kleyboldt.conf
WSGIPythonPath /var/www/kleyboldt:/var/www/kleyboldt/env/lib/python2.7/site-packages
<VirtualHost *:80>
WSGIScriptAlias / /var/www/kleyboldt/kleyboldt.wsgi
ServerName kleyboldt.com
Alias /static /var/www/kleyboldt/static
<Directory /var/www/kleyboldt/>
Require all granted
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
/etc/apache2/sites-available/kleyboldt2.conf
WSGIPythonPath /var/www/kleyboldt2:/var/www/kleyboldt2/env/lib/python2.7/site-packages
<VirtualHost *:80>
WSGIScriptAlias / /var/www/kleyboldt2/kleyboldt2.wsgi
ServerName kleyboldt2.com
Alias /static /var/www/kleyboldt2/static
<Directory /var/www/kleyboldt2/>
Require all granted
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Afterwards I enabled both sites via a2ensite. I checked the sites-enabled directory and the links are placed correctly. In order to redirect kleyboldt.com and kleyboldt2.com to my local apache I changed my /etc/hosts to:
127.0.0.1 localhost
127.0.1.1 mars (name of my computer)
127.0.0.1 kleyboldt.com
127.0.0.1 kleyboldt2.com
To use WSGI I wrote for each project a seperated wsgi file in the project folder:
/var/www/kleyboldt/kleyboldt.wsgi
import os
import sys
sys.path.append('/var/www/kleyboldt')
os.environ['DJANGO_SETTINGS_MODULE'] = 'kleyboldt.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
/var/www/kleyboldt2/kleyboldt2.wsgi
import os
import sys
sys.path.append('/var/www/kleyboldt2')
os.environ['DJANGO_SETTINGS_MODULE'] = 'kleyboldt2.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
I created two independent python environments using virtualenv that are now located under /var/www/kleyboldt/env and /var/www/kleyboldt2/env.
Afterwarsd I got two django test sites when I typed both domains in the URL bar of my browser. To differ I added some settings to the settings.py files and wrote custom views.
/var/www/kleyboldt/homepage/views.py
from django.http import HttpResponse
def hello(request):
return HttpResponse("kleyboldt1")
/var/www/kleyboldt2/homepage/views.py
from django.http import HttpResponse
def hello(request):
return HttpResponse("kleyboldt2")
When I type localhost in my browser then I get kleyboldt2 back. When I type kleyboldt2.com in my browser then I get kleyboldt2 back too. Unfortunately I see kleyboldt2 also after typing kleyboldt.com in my browser.
Maybe the bug is to simple for me to discover :D Does anybody know a possible solution?
My Flask and mod_wsgi app seems to be breaking ports. Every month or so my page will stop loading and I get a "Google Chrome could not connect to " message, but moving it to a new port fixes it. I've checked the apache log and there doesn't seem to be anything wrong there. If I stop apache from listening to the port and run my dev version of the Flask app on one of the ports that the live version has previously used I get the same "Google Chrome could not connect to " message. While apache is listening Netstat shows that the port is being listened to by apache and lsof -i returns a bunch of apache processes that are using the port. I'm not sure if any of that is normal for mod_wsgi. If I remove the port from apache both netstat and lsof return nothing but the port still doesn't work for mod_wsgi or flask.
Here is the mod_wsgi part of my config file with the ip, domain, and user/group changed
<VirtualHost 0.0.0.0:8880>
ServerName test.example.com
DocumentRoot /var/www/html
WSGIDaemonProcess dash user=user group=group threads=5
WSGIScriptAlias / /var/www/html/dash/dashboard.wsgi
<Directory /var/www/html/dash>
WSGIProcessGroup dash
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
# records regular flask errors
ErrorLog /var/www/html/dash/error.log
LogLevel warn
Here is my wsgi file
import os
import sys
# location of flask app
sys.path.insert(0, '/var/www/flask/dashboard')
from dashboard import app as application
# logs python errors at production.log
if not application.debug:
import logging
this_dir = os.path.dirname(__file__)
log_file = os.path.join(this_dir, 'production.log')
file_handler = logging.FileHandler(log_file)
file_handler.setLevel(logging.WARNING)
application.logger.addHandler(file_handler)
Rewriting the virtual host without an ip address seems to have fixed the issue.
<VirtualHost *:8880>
Thanks to the mod_wsgi user group who found the answer [https://groups.google.com/forum/#!forum/modwsgi][1]
I'm using centos, apache, mod_wsgi on server for django project.
After uploading over sftp of changed project files site opens with changes and without changes randomly.
I think, that changes should not be applied before restarting apache. Isn't it?
Apache settings
<VirtualHost *:88>
ServerName h1.ru
UseCanonicalName Off
ServerAdmin "admin#h1.ru"
DocumentRoot /var/www/h1/h1.ru/
AllowEncodedSlashes On
WSGIDaemonProcess h1 processes=4
#WSGIProcessGroup h1
WSGIScriptAlias /site /var/www/h1/pyh1/h1/wsgi.py
Alias /static /var/www/h1/pyh1/static
<IfModule mod_ssl.c>
SSLEngine off
</IfModule>
<Directory /var/www/h1/h1.ru>
php_admin_flag engine on
php_admin_flag safe_mode off
php_admin_value open_basedir "/var/www/h1/h1.ru:/tmp"
Options -Includes -ExecCGI
</Directory>
</VirtualHost>
wsgi:
#!/usr/local/bin/python2.7
import os
import sys
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), "..")))
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "h1.settings")
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
Not true. Normally mod_wsgi will run in multiple separate processes, managing their startup and shutdown automatically. When a new process starts, Python code will be loaded from disk as it is imported, so that process will run with the newest versions of any files. Meanwhile, any processes that were already alive will use the versions they had previously loaded, so will not reflect the changes (unless a little-used code path is activated which leads to importing a so-far-unimported module).
Certainly the only way to be sure you have the latest choose in all processes is to restart Apache.
I am running a ec2 instance to host some Django websites. The websites are being served by Apache with the use of mod_wsgi
Since a few days I am trying to deploy a new webplatform we are developing but I am running into a problem that seems impossible for me to solve. For security reasons we use scrypt 0.4 to secure the users personal information like passwords.
On the development server everything works like a charm but when we deploy to our live server we get a 500 Internal Server error. The apache log gives me the following message
Premature end of script headers: socialmarketingplatform.wsgi, referer:
When I uncomment the line where the scrypt module is used everything works fine. Also when I run the server delivered with Django with scrypt enabled everything works on the live server. So it is a combination of mod_wsgi, django and scrypt that generates the error.
I am using the following wsgi file:
import os
import sys
path = '/var/www/vhosts/[sub_domain]'
if path not in sys.path:
sys.path.append(path)
sys.path.append(path + '/socialmarketingplatform')
os.environ['DJANGO_SETTINGS_MODULE'] = 'socialmarketingplatform.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
And the following virtualhost config:
<VirtualHost *:80>
#Basic setup
ServerAdmin [removed email]
ServerName luxdevelopment.net
ServerAlias [sub domain]
DocumentRoot /var/www/vhosts/[sub domain]/socialmarketingplatform/
Alias /media/admin /usr/lib/python2.6/site-packages/Django-1.3-py2.6.egg/django/contrib/admin/media
Alias /media /var/www/vhosts/[sub domain]/socialmarketingplatform/media
<Location media="">
SetHandler None
</Location>
LogLevel warn
ErrorLog /var/log/httpd/smp_error.log
CustomLog /var/log/httpd/smp_access.log combined
WSGIDaemonProcess luxdevelopment.net user=apache group=apache threads=25
WSGIProcessGroup luxdevelopment.net
WSGIScriptAlias / /var/www/cgi-bin/socialmarketingplatform.wsgi
</VirtualHost>
I hope someone can help me with this problem. If there are any further question let me know.
See:
http://code.google.com/p/modwsgi/wiki/FrequentlyAskedQuestions#Apache_Process_Crashes
The message 'premature end of script headers' is usually indicative of your code crashing the daemon process. You can verify this by looking for segmentation fault or similar message in main Apache error log file. If you enable 'LogLevel info' in main Apache config and VirtualHost then mod_wsgi will log more about daemon process restarts.
A quick remedy if running only application in that daemon process group is to add:
WSGIApplicationGroup %{GLOBAL}
This will work around crashes caused by broken third party extension modules for Python which aren't written properly to work in sub interpreters.
Other than that, can be shared library version mismatches as described in the FAQ.