26 replies to this topic

[albertoc]

Hi guys,

thanks for your great work!

 

I'd like to ask you whether there's a chance to have django on tommy, or on any other server.

(I followed the instructions in the wiki to get django working, and then I discovered that isn't supported on tommy)

 

account: albertoc

site: sest.gq

 

 

Cheers!

[Krydos]

We hadn't installed Django on Tommy yet because no one had asked for it. Since you asked, Django 1.10.5 is now installed on Tommy running on Python 3.6.0.

• To get started download https://www.heliohos...angotest.tar.gz
• Upload this archive to /home/<USERNAME>/public_html
• Extract the archive and it will create a djangotest directory in public_html
• Edit djangotest/dispatch.wsgi
• Change <USERNAME> to your cPanel username
• Edit djangotest/settings.py
• Change <DOMAIN> to your account's domain
• Go to <DOMAIN>.heliohost.org/djangotest

If it worked you should see the Django welcome page like https://krydos.helio...org/djangotest/

[albertoc]

Hi Krydos,

thanks for your work.

 

I'm still having troubles setting up django on my account: I set up both settings.py and dispatch.wsgi as you said (dispatch.wsgi: http://pastebin.com/HbiTwDWN , settings.py: http://pastebin.com/kd3Khpdz).

 

sest.gq/djangotest/ doesn't work, returning a 500 internal server error.

but also a simple /index.html file with an hello world doesn't work, with the same 500 error message.

 

are there problems on tommy? or could the problem be that I'm using an external domain?

[Byron]

I've renamed your .htaccess file in your home directory so now your site is giving a 500 error.

 

http://sest.gq/index.html

 

I suspect the reason why your djangotest isn't working is because of this line here in your dispatch.wsgi file:

# edit your username below
sys.path.append("/home/sest.gq/public_html/djangotest");

You need to replace your domain name with your username like it says.

[albertoc]

Hi Byron!

 

I changed the line in the dispatch.wsgi with my username, and djangotest is now working as Krydos' one.

 

 

Now I'm trying to adapt it to my project ( https://github.com/bebosudo/sest ): my project has a folder weather_station_website, which manages django settings and configs, and an app called sest in its relative folder sest/, which contains the actual project data.

 

I'd like to set up the server so that when I access sest.gq I'm actually being redirected by the django "router" weather_station_website/urls.py.

 

My folder tree is now:

/home/albertoc/public_html/

|-- djangotest/

   |-- ...

|-- media/                                 # an empty folder to test the .htaccess rules

|-- sest/                                    # app data: they are the same present on github

|-- weather_station_website/

   |-- dispatch.wsgi

   |-- settings.py

   |-- urls.py (and other django files)

|-- .htaccess

|-- _index.html                         # a html testing file, now it can't be seen due to the htaccess rules

 

 

The htaccess file seems to work, since I cannot see the _index.html file (but the djangotest/ folder is curiously still accessible).

Still when I point to sest.gq I get a 500 error.

[Byron]

I can't help you with your project but I can help you with your 500 error. Your error is still in your .htaccess file. I've renamed your .htaccess to old-htaccess and now your site is working:

 

http://sest.gq/_index.html

[Krydos]

@byron, What the .htaccess file does on a django site in this example is force everything (other than static files in the media folder) to be processed through dispatch.wsgi. That's what ties the whole thing together as django rather than seperate html files etc. If the django site itself has a 500 error renaming the .htaccess just makes the django not process at all.

 

@albertoc, the 500 error is because (as I explained about) /home/albertoc/public_html/.htaccess is trying to send all requested to be processed by /home/albertoc/public_html/dispatch.wsgi but that file doesn't exist.

[Byron]

@Krydos, the reason his django site was throwing a 500 error was because of this line here in his dispatch.wsgi file:

 

# edit your username below
sys.path.append("/home/sest.gq/public_html/djangotest");

 

I never deleted the .htaccess in his django folder only in his public_html directory. I had to rename it twice to remove the 500 error.

[albertoc]

@byron
You were right, I was pointing the wrong path in the dispatch.wsgi file, but then I changed it, as you can see in the pastebin (in the tree list in my last post).

@krydos
In the .htaccess ( http://pastebin.com/raw/WvqS8YNM ) I'm redirecting all the traffic to /weather_station_website/dispatch.wsgi (which is RewriteBase + the last regex that greps everything).
Is it wrong? Why doesn't it still work?

Many thanks

[Krydos]

@byron that was the reason /home/albertoc/public_html/djangotest/.htaccess was throwing a 500 error yesterday. He has fixed that and I was explaining why /home/albertoc/public_html/.htaccess was throwing a 500 error today which is the file you renamed.

 

@albertoc there are a couple things going on here. First of all manage.py is pointless to upload since you don't have shell access so you may as well delete that to reduce the chance of security holes. Second since this isn't a dedicated django server the structure of your application is going to need to be a little different. On a dedicated django server like your application is set up to run on everything other than the media directory would be processed through mod_wsgi, but this is a shared server and the hundreds of other people sharing the server with you don't want the performance hit of everything being processed twice like that. The .htaccess rules is how you specify that you want things to be processed through your dispatch.wsgi file. In your application this is called wsgi.py, but it won't run like that because not all .py files on the server necessarily have to be django files. I have it set up so everything with the extension .wsgi is processed as django. Any other extension will not be processed through mod_wsgi. This is the key to tying the whole thing together. Simply renaming that file and setting up the proper rules in .htaccess so everything is processed correctly through the .wsgi file should be enough to get you going.

I messed around with your files for a bit, but I can't get it working either and I've run out of time for now. I'll be back to fiddle with it some more later.

[Krydos]

Well, I made some progress on it, but now it looks like it's having some path related issues: http://sest.gq/

At least it's throwing helpful errors now instead of useless 500 errors.

[albertoc]

Many thanks Krydos for the time you are spending on my issue!

 

There was an error in the second import in my settings.py file, because I was importing the file with the passwords with the dot notation in front, because I didn't place an empty __init__.to mark the folder as a package) as you did.

So now there's still an error, but at least is a django error and not a meaningless 500 internal server error as before.

 

Now the error is related to django, and in particular it states that it's not able to find the sqlite3 db file anymore: another error thrown was because it wasn't able to locate the template folder.

 

This happens because we moved the settings.py, urls.py and the dispatch.wsgi files out from the "website settings" folder (called weather_station_website) to the root (/home/albertoc/public_html/) folder.

This also means that the whole structure is now completely messed up , because django expects the config files to be in a separate folder, as specified in the manage.py file (link): weather_station_website.settings

 

 

Is there a way to leave the setting and config files in the "settings" folder, and forward the requests to that setting files?
something like:

1. a request is sent to sest.gq/url
2. /url gets processed by public_html/.htaccess
3. public_html/.htaccess forwards this to public_html/dispatch.wsgi (or public_html/weather_station_website/dispatch.wsgi)
4. inside public_html/dispatch.wsgi (or public_html/weather_station_website/dispatch.wsgi) sys.path is set to public_html/ (or public_html/weather_station_website/)
5. the dispatch file starts up the normal django execution flow.

and the files should be organized as follows:

public_html/

|-- sest/                                    # app files

|-- weather_station_website/

    |-- __init__.py

    |-- settings.py

    |-- urls.py

|-- dispatch.wsgi                      # here, or maybe inside the settings folder, weather_station_website/ .. ?

|-- .htaccess

 

(in the preceding paragraphs with public_html/ I mean the public_html folder of my account, located at /home/albertoc/public_html/)

 

could this arrangement be possible (which is the "normal" layout that is set up when a new project is created with

$ django-admin startproject mysite

) ?
otherwise I should deeply mess up with the django settings files in order to force the reading from the public_html/ folder.

 

[Krydos]

Yeah, of course you can. The reason I did a structure like I did is because I started with our old djangotest.zip file which was originally created with like django 1.2 or something ancient, and adapted it to work with the newest django 1.10 that I installed. I'm guessing that's how the django-admin startproject command did things back then, but you're right that command has a very different structure in the latest version.
 
Using python 3.6 and django 1.10 on my home computer I created a project called hello which looks like this

/hello/
      /db.sqlite3
      /manage.py
      /hello/
            /__init__.py
            /wsgi.py
            /settings.py
            /urls.py

Obviously it doesn't work, as you found out already, if you just upload it like that. So we need to make a few changes. The most important things are the .htaccess to force django to process the files, and the .wsgi file that ties it all together. So on the server it looks like this so far:

/public_html/
            /db.sqlite3
            /.htaccess
            /hello/
                  /__init__.py
                  /dispatch.wsgi <----- simply wsgi.py renamed
                  /settings.py
                  /urls.py

And the code for the .htaccess is this

RewriteEngine On
RewriteBase /
RewriteRule ^(media/.*)$ - [L]
RewriteRule ^(admin_media/.*)$ - [L]
RewriteRule ^(hello/dispatch\.wsgi/.*)$ - [L]
RewriteRule ^(.*)$ hello/dispatch.wsgi/$1 [QSA,PT,L]

Obviously, the last two lines replace "hello" with whatever the name of your project is.

This still won't work though because the wsgi.py/dispatch.wsgi file doesn't have the paths correct for running on the production server yet. Here is what django-admin created

import os

from django.core.wsgi import get_wsgi_application

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "hello.settings")

application = get_wsgi_application()

This is what I changed it to which works both locally and on Tommy

import os, sys

# edit your username below
sys.path.append("/home/krydos1/public_html")

from django.core.wsgi import get_wsgi_application

os.environ['DJANGO_SETTINGS_MODULE'] = 'hello.settings'

application = get_wsgi_application()

Now, when you make a change to wsgi.py locally also copy it to dispatch.wsgi before you upload it.

Here is my test case with the django project running on the root of the domain (instead of in a folder like on my main account). http://krydos1.heliohost.org/

[Krydos]

Oh yeah, one other thing. The command django-admin startproject command creates your settings.py file with

ALLOWED_HOSTS = []

Django on Tommy will report an error unless you specify your domain or use a wildcard there.

ALLOWED_HOSTS = ['*']

Specifying an exact domain will be more secure, but for the future people who may read this the * will work for all of your websites.

[albertoc]

Wow Krydos, what a detailed tutorial!

 

Again, many thanks for your work: now django is running as a charm on sest.gq

 

Thanks again guys for the patience and the time you spend on this community :-)