I'm running two django projects in IIS with wfastcgi enabled. The first django project is running without an issue but the second project displays a blank page (code 200) returned.
Second Project Info:
A virtual folder, within it's own application pool in IIS, is created to host the second project. The second project was created in an python environment folder. The second project runs from django using python manage.py runserver 0.0.0.0:8080, but displays a blank page when browsing to the virtual folder page.
The root folder was granted with "everyone" full control access to all sub-folders
for the second project, wfastcgi application and handler is pointing to the virtual environment python and wfastcgi file correctly.
Can you have two wfastcgi applications and handlers "Second Python FastCGI"
C:\project_folder\project_env\Scripts\python.exe|C:\project_folder\project_env\lib\site-packages\wfastcgi.py"
I wanted them separate so that two developers don't interfere with each others work, but they need to run within the same server and port.
I resolved the problem by editing the web.config file and removing the static handler from it. The static handler was being used instead of the FastCgiModule handler. The static handler should be moved below the FastCgiModule.
Related
I want to have a production ready Django app with Lighsail and for that I'm following two tutorials to achieve this
Deploy Django-based application onto Amazon Lightsail
Deploy A Django Project
From the Bitnami article can see that the AWS documentation follows its Approach B: Self-Contained Bitnami Installations.
According to:
AWS's documentation, my blocker appears in 5. Host the application using Apache, step g.
Bitnami's documentation, where it says
On Linux, you can run the application with mod_wsgi in daemon mode.
Add the following code in
/opt/bitnami/apps/django/django_projects/PROJECT/conf/httpd-app.conf:
The blocker relates to the code I'm being asked to add, in particular the final part that has
Alias /tutorial/static "/opt/bitnami/apps/django/lib/python3.7/site-packages/Django-2.2.9-py3.7.egg/django/contrib/admin/static"
WSGIScriptAlias /tutorial '/opt/bitnami/apps/django/django_projects/tutorial/tutorial/wsgi.py'
More specifically, /home/bitnami/apps/django/. In /home/bitnami/ can only see the following folders
. bitnami_application_password
. bitnami_credentials
. htdocs
. stack
and from them the one that most likely resembles /opt/bitnami/apps/ is /home/bitnami/stack/. Thing is, inside of that particular folder, there's no django folder - at least as far as I can tell (already checked inside some of its folders, like the python one).
The workaround for me at this particular stage is to move to a different approach, Approach A: Bitnami Installations Using System Packages (which I've done and managed to make it work as wrote in this blog post), but I'd like to get it to work using Approach B and hence this question.
The problem here is in the mentioning of the paths for both the project and Django.
In my case, projects are under /home/bitnami/projects/ where I created a Django project named tutorial.
Also, if I run the command
python -c "
import sys
sys.path = sys.path[1:]
import django
print(django.__path__)"
it'll print me the location where Django is installed
['/opt/bitnami/python/lib/python3.8/site-packages/django']
So, the httpd-app.conf should have instead at the end
Alias /tutorial/static "/opt/bitnami/python/lib/python3.8/site-packages/django/contrib/admin/static"
WSGIScriptAlias /tutorial '/home/bitnami/projects/tutorial/tutorial/wsgi.py'
I am quite new to Apache and WSGI, there are a lot of things confusing me.
After a fresh install of apache2 on ubuntu, I can open this URL to see the default apache page http://localhost/index.html, the file is residing in /var/www/html. So this is the function that apache server provices, serving http connection.
Here's the current situation:
I've created a simple Django project and install mod_wsgi onto my apache server,and finally I managed to deploy the project to apache and the page iIve created can be accessed correctly.
BUT now when I try to access the index.html i mentioned above, it shows the url mapping cannot be found(yes I do not have this mapping in the django project).Is Django taking over all the path that point to the server?
How can I make the django project only map to a specific path like http://localhost/Django/[MY URL MAPPING] and keep other url mapping untouched.
So I can access the static HTML(index.html) by accessing http://localhost/index.html/ and access my Django project by accessing http:/localhost/Django/[xxx]
Is this possible? or I have to use another virtual host at another port?
Any help will be much appreciated.
You can do this by mounting Django at a different point:
WSGIScriptAlias /Django /path/to/mysite.com/mysite/wsgi.py
This runs the WSGI application at /Django, and leaves Apache to serve the rest of the files directly.
I have a Django project which I would like to run on my shared webspace (1und1 Webspace) running on linux. I don't have root access and therefore can not edit apache's httpd.conf or install software system wide.
What I did so far:
installed squlite locally since it is not available on the server
installed Python 3.5.1 in ~/.localpython
installed virtualenv for my local python
created a virtual environment in ~/ve_tc_lb
installed Django and Pillow in my virtual environment
cloned my django project from git server
After these steps, I'm able to run python manage.py runserver in my project directory and it seems to be running (I can access the login screen using lynx on my local machine).
I read many postings on how to configure fastCGI environments, but since I'm using Django 1.9.1, I'm depening on wsgi. I saw a lot about configuring django for wsgi and virtualenv, but all examples required access to httpd.conf.
The shared web server is apache.
I can create a new directory in my home with a sample hello.py and it is working when I enter the url, but it is (of course) using the python provided by the server and not my local installation.
When I change the first line indicating which python version to use to my virtual environment (#!/path/to/home/ve_tc_lb/bin/python), it seems to use the correct version in the virtual environment. Since I'm using different systems for developing and deployment, I'm not sure whether it is a good idea to e.g. add such a line in my djangoproject/wsgi.py.
Update 2016-06-02
A few more things I tried:
I learned that I don't have access to the apache error logs
read a lot about mod_wsgi and django in various sources which I just want to share here in case someone needs them in the future:
modwsgi - IntegrationWithDjango.wiki
debug mod_wsgi installation (only applicable if you are root)
mod_wsgi configuration guide
I followed the wsgi test script installation here - but the wsgi-file is just displayed in my browser instead of beeing executed.
All in all it seems like my provider 1und1 did not install wsgi extensions (even though the support told me a week ago it would be installed)
Update 2016-06-12: I got a reply from support (after a week or so :-S ) confirming that they dont have mod_wsgi but wsgiref...
So I'm a bit stuck here - which steps should I do next?
I'll update the question regularly based on comments and remarks. Any help is appreciated.
Since your apache is shared, I don't expect you can change the httpd.conf but use instead your solution. My suggestion is:
If you have multiple servers you will deploy your project (e.g. testing, staging, production), then do the following steps for each deploy target.
In each server, create a true wsgi.py file which you will never put in versioning systems. Pretty much like you would do with a local_settings.py file. This file will be named wsgy.py since most likely you cannot edit the apache settings (since it is shared) and that name will be expected for your wsgi file.
The content for the file will be:
#!/path/to/your/virtualenv/python
from my_true_wsgi import *
Which will be different for each deploy server, but the difference will be, most likely, in the shebang line to locate the proper python interpreter.
You will have a file named my_true_wsgi to have it matching the import in the former code. That file will be in the versioning systems, unlike the wsgi.py file. The contents of such file is the usual contents of the wsgi.py on any regular django project, just that you are not using that name directly.
With this solution you can have several different wsgi files with no conflict on shebangs.
You'll have to use a webhost that supports Django. See https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts. Personally, I've used WebFaction and was quite happy with it, their support was great and customer service very responsive.
I am using a digital ocean virtual server to host a django web app. when you create the droplet, it creates a default app in the directory /home/django/django_project/django. However seeing as this isn't the app I want to host, I put my application files into the directory /home/myproject/myapp and updated the gunicorn and nginx configs to point there. However once updating the urls for this app, I am trying to see it online and noticed that the 404 looked like this:
which states that the URLconf is defined in django_project.urls which I had since deleted out of that 'home/django directory. I have reloaded and restarted gunicorn and nginx in an attempt to get django to realize that the project django_project doesn’t exist any more, but no luck. Has anyone run into this before or have any suggestions as to what I should try next?
I started from the Django template application in OpenShift, pushed it to OpenShift, and it ran without issue. After making a couple minor changes to settings.py and /.openshift/action_hooks/deploy, the application no longer runs (404 not found). In the command window, during deployment, I see CLIENT_ERROR: WSGI application not found. The build/deploy succeeds and finishes deployment.
As stated before, the home page now returns a 404. The logs indicate that application.py is not found. If I SSH into the deployment folder, I can find the file exactly where it is reported missing. Any ideas?
What changes did you make? If you changed the entry point you need to update your OPENSHIFT_PYTHON_WSGI_APPLICATION environment variable as per this release article: https://www.openshift.com/blogs/openshift-online-march-2014-release-blog