I have some django projects that I worked on and I want to deploy them with wamp server. I want that my structure would look like this:
/www
/project1
/static
/media
/templates
/project1
/settings.py
/urls.py
/app1
/app2
/project2
/static
/media
/templates
/project1
/settings.py
/urls.py
/app1
/app2
Then the urls would point to:
http://localhost/project1/(urls of project1)
http://localhost/project2/(urls of project2)
Each project uses a different database, a different admin site (some customized), and so on. I will never need to share data between them. I tried searching and reading about it, and using multiple WSGI scripts seems really buggy. Also as I understand it, I can't use the recommended daemon mode because I'm using windows.
Is it frowned upon to use multiple wsgi scripts on the same server? Should I try to create one that will handle all the projects? How would it look like, and how would the apache be configured to work with it? Is my intended structure above completely wrong?
I am using Apache 2.2e with mod_wsgi 3.3, Django 1.5.1 and python 2.7
No it is not frowned on to use multiple WSGI scripts and doing so is not buggy as such, except to the extent that Django generates a dodgy WSGI script file which you need to change to ensure you don't get environment variable leakage.
That said, you may still have issues with third party C extension modules for Python which are broken and don't work in sub interpreters, which is why it is preferred to use daemon mode if you can, as you can workaround such buggy third party modules.
So overall there is no issue with mod_wsgi, but you may encounter issues if using other software which uses a sub optimal way of configuring things, or which are broken by design.
Personally I would suggest simply not using Windows as it is a poor environment to be running Python web applications. Only use Windows if you have absolute no choice.
Related
I want to run my Django app created in virtualenv on ubuntu with python3. Folder structure in virtualenv folder:
-bin
-include
-lib
-myapp
-share
pip-selfcheck.json
The myapp folder contains my application with apache folder configured as specified in this tutorial: https://www.sitepoint.com/deploying-a-django-app-with-mod_wsgi-on-ubuntu-14-04/
I have all apps installed I need in my virtualenv, after 'sudo service apache2 restart' I see only Apache2 Ubuntu Default Page.
File /etc/apache2/sites-enabled/000-default.conf is like in the tutorial:
<VirtualHost *:80>
WSGIScriptAlias / /home/myuser/mysite/apache/wsgi.py
<Directory "/home/myuser/mysite/apache/">
Require all granted
</Directory>
</VirtualHost>
Of course with correct paths pointing to my project location in 'venv' folder.
No idea where to move on, what to check, thanks for suggestions.
EDIT:
I realy dont get this, I edited the mentioned file, had a try, nothing happened so I edited it back and after restart it it worked.
The official Django documentation on using mod_wsgi can be found at:
https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/modwsgi/
It may be better to consult that for how to set things up specifically for Django, you are missing various required configuration elements.
As to why you are still getting the default page, it could be because you added that configuration as an extra thing to the end of the default sites file, rather than inserting the contents of the VirtualHost you have into the existing VirtualHost in that file. If you added it after, it will be ignored as it will still use the existing VirtualHost as it comes first and you haven't set up correctly named based hosting.
Also be aware that where other people say you should use something else, every solution will have a learning curve if this is all new. No solution is simple if you want to integrate into your existing host system. So jumping around looking at different solutions can be a great waste of time. Select one which you think you like and stick with it. The idea that one is superior to others is in general nonsense as their performance is similar.
I would actually suggest you skip even trying to integrate it into your host system to begin with if you are just playing. Use a WSGI server that you can run from the command line, even if it is just the bundled development server with Django. Options which are simple to run from the command line are:
mod_wsgi-express
gunicorn
So after editing the file, restarting apache, editing the file back it works (/etc/apache2/sites-enabled/000-default.conf). Really dont get it, several restarts yesterday did not help...
I have Ubuntu 20.04 and Apache2. I followed the mod_wsgi installation instructions linked to here but forgot to enable the module in /etc/apache2/apache2.conf (or to include a file from apache2.conf that does so). I added that and then the WSGIScriptAlias / /home/myuser/mysite/apache/wsgi.py directive in my 000-default.conf did not cause an error when I restarted the server with systemctl restart apache2
I'm in a university and I'm provided with a public_html folder where I can put my CGI scripts. For eg. when I put PHP scripts and visit them from my browser, it works correctly and the PHP is properly interpreted.
I wish to run Django apps in this environment and I know that the university runs an apache server and had mod_php and mod_python installed, although I think I'm not allowed to modify the httpd.conf etc.
All the tutorials that I've read about Django on mod_python ask me to modify the httpd.conf, is there any way I can get my Django site running by making non-sudo changes only?
You can try to put your directives in a .htaccess file in your directory. Dependent on the server config, it might work.
I have a Django app set up with Apache and mod_wsgi and it's working fine. I have a Zinnia blog under the same app functioning at the /blog/ subdirectory. So, the blog is www.mysite.com/blog/. What I wanna do is have blog.mysite.com/ point to the /blog/ subdirectory. I'm stumped because I don't know if I should do this through Django or Apache. So, any ideas?
This has to be done with Apache config.
I think you have to setup a Reverse Proxy, which will listen to blog.mysite.com domain and proxy requests to www.mysite.com/blog/.
Unfortunately I'm not an Apache pro, so can't help you with configuration.
Completely from memory and can't test it right now, but in the VirtualHost for blog.mysite.com mount it as:
WSGIScriptAlias / /some/path/wsgi.py/blog
In other words, you still mount it with mod_wsgi, but add '/blog' to the end of the target WSGI script path. This should from memory cause Apache and mod_wsgi to remap things so that '/blog' automatically gets added as part of the URL seen by the Django application. Thus it should map to the blog mapped at that location in the URL namespace in the Django urls.py.
Do note that because you are doing it with a distinct WSGIScriptAlias, it will actually load up a second copy of your Django site in memory in a different sub interpreter than the first one. If that is undesirable, you can use WSGIApplicationGroup directive to override which application group they are both running in and set them to be the same. Preferably use mod_wsgi daemon mode if you aren't already and have them run distinct from the Apache child worker processes as well, as that is generally better than using embedded mode.
what is the underlying infrastructure Django uses to handle its requests?
did it use thread, can someone give some reference on this ?
Django is not a web server. It is a web framework. The behavior of how it is being run as an application is dependant on your method for serving it.
It could be threaded requests. It could be processes. It could even be async.
Serving Files
Django doesn't serve files itself; it leaves that job to whichever Web server you choose.
Wsgi is the most common way to serve django right now, so really you should just investigate the configuration options of different wsgi implementations.
If you get random segmentation faults when using manage.py runserver because some underlying C libraries you have to use in your project are not thread-safe, try
manage.py runserver --nothreading
instead.
For production services that run wsgi with tools like mod_wsgi, there is usually an option to disable threading. In this case
WSGIDaemonProcess example processes=5 threads=1
See https://modwsgi.readthedocs.io/en/develop/user-guides/processes-and-threading.html
I am very new to apache and django, so execuse me if this question is simple. I am trying to deploy an existing site to an apache server. For the time being, the site is still in development so I am only deploying it as a virtualhost on my local machine.
I am using Django's WSGI module in the deployment. In my site's config file, I have the following aliases:
Alias /media/ /home/tester/Desktop/siteRootDir/media
Alias /content/ /home/tester/Desktop/siteRootDir/content
WSGIScriptAlias /c /home/tester/Desktop/siteRootDir/deploy/site.wsgi
When I run apache and go to localhost/c I was getting the (13)PermissionDenied error in the apache log. To get around that error, I (admitedly stupidly) ran
chmod -R 777 /home/tester/Desktop/siteRootDir
I know that is not the way to deal with the issue, but I just wanted the site to work so I can continue its development.
So my question is, what are the correct permission settings to the siteRootDir directory and its sub-directories such that the site will run and I do not expose unnecessary files in the directory.
Also, I realize that this is not an ideal set up and I will likely run into problems when I deploy the site in production. Can anyone please suggest a better organizational approach to this?
Thanks!
The tightest permissions possible would be 0600 for files and 0700 for dir's and as a owner the user owning the apache processes. This user differs per OS and flavor (e.g. for OSX it's www, for Debian/Ubuntu it's www-data).
This would probably too tight for a development server. At least would you like to be able to modify all your files through your IDE of text editor, so either you should add ACLs for yourself (i.e. the user that edits the Django files, templates and static files).
Also, in a production server you want the apache user to be able to write to directories that hold web uploaded content. That would be somewhere in your static files section (or on a different dedicated static files server).