Django i Dreamhost
Mam nadzieję, że to kompletny poradnij jak uruchomić Django na DreamHoście.
Przewodnik ten miał pokazać jak zainstalować Django na DreamHoście z użyciem Virtual Pythona (proces opisany tu). Niestety miałem z tym pewne problemy i postanowiłem opublikować wersję w pełni sprawdzoną. Wysłałem w tej sprawie maila do supportu i jeżeli jakoś to wyjaśnią opiszę w szczegółach ten drugi schemat - moim zaniem dużo “ładniejszy”.
Przewodnik ten jest w większości oparty na tym co już w sieci jest: Jeff Croft, wiki.dreamhost.com. Nie skupiam się tu na konfiguracji aplikacji lecz na konfiguracji samego konta na DreamHoście.
Jeżeli chcesz założyć konto na DreamHoście możesz przed płatnością podać kod: DJANGOPL, który da Ci zniżkę w wysokości 60 USD a jednocześnie DreamHost przekaże nam 37 USD na hosting pod różne projekty (między innymi tego bloga i django.pl). Dobra dość z reklamami - zaczynamy.
Uwaga/wyjaśnienie: ‘~‘ tak jak zmienna systemowa $HOME na systemach UNIXowych znaczy katalog domowy.
Po pierwsze w panelu administracyjnym w zakładce “Users -> manage users”, dodajemy użytkownika (zaznaczamy “Shell account”, jako “Shell: /bin/bash”). W naszym przypadku użytkownik nazywa sie sandpit_djangopl
Dodajemy domenę/subdomenę “domains -> manage domains”. Musimy ustawić domenę, która będzie obsługiwała FCGI (zaznaczamy “FastCGI Support?”). Jako użytkownika FTP/CGI (”FTP user / CGI-runs-as user:”) wybieramy przed chwilą stworzonego użytkownika. W naszym przypadku domeną będzie sandpit.django.pl
Ważne: jeden użytkownik systemowy, którym ma uruchamiać procesy FCGI powinien mieć tylko jedną domenę/subdomenę.
Przykład: użytkownik djangopl, który obsługuje domenę django.pl (na której działa aplikacja FCGI, czyli procesy o nazwie dispatch.fcgi - tylko tej nazwy DreamHost nie zabija gdy długo chodzą) nie powinien obsługiwać również subdomeny np sandpit.django.pl, pod którą ma działać inna aplikacja FCGI. Jeżeli w tej kwestii jednak się mylę proszę poprawcie mnie.
Mamy już użytkownika i domenę. Logujemy się na niego używając SSH (na Windowsie możemy użyć puTTY)
-
ssh username@host
W moim przypadku:
-
ssh sandpit_djangopl@sandpit.django.pl
Ściągamy Flupa - będzie nam serwował FastCGI. Mamy dwie możliwości: wersję “stabilną” (0.5 na dziś - teoretycznie stabilne projekty zaczynają się od wersji 1.0): Skupimy się tu na wersji z SVN:
-
svn co http://svn.saddi.com/flup/trunk ~/flup_src/
Ściągamy kod źródłowy Django z SVN (możemy też zainstalować wersję stabilną z paczki ale ta na dziś to 0.95 i nie zawiera choćby newforms):
-
svn co http://code.djangoproject.com/svn/django/trunk/ ./django_src
Teraz sprawmy by django-admin.py był dostępny w konsoli (pomocne gdy tworzymy projekt od zera) - modyfikujemy zmienną systemową wyszukiwania $PATH (jeśli sam ją modyfikowałeś, może to dać różne rezultaty) oraz $PYTHONPATH - miejsca, w których Python wyszukuje modułów.
-
echo "export PATH=$PATH:$HOME/django_src/django/bin" >> ~/.bash_profile
-
echo "export PYTHONPATH=$PYTHONPATH:$HOME/django_src:$HOME/django_projects" >> ~/.bash_profile
-
source ~/.bash_profile
Mała rada co do .bash_profile w pliku znajduje się wpis, który dotyczy wyświetlania promptu BASHowego: PS1=”[\h ]$ ” ja zmieniam go na: PS1=”[\h \w]$ ” by pokazywał katalog, w którym jestem.
Django mamy zainstalowane więc możemy wrzucić nasz projekt i go odpowiednio skonfigurować (w tym przypadku projekt nazywa się djangopl i umieszczony zostanie w katalogu ~/django_projects/):
-
mkdir ~/django_projects/
-
cd ~/django_projects/
W katalogu ~/django_projects/ umieszczamy nasz projekt np. pobieramy go z SVN, kopiujemy przez FTP lub SSH wedle uznania. Gdy to juz zrobiliśmy, zmieniamy uprawnienia do pliku settings.py i zmieniamy jego zawartośc wedle uznania (dane bazy danych, debug itd). W tym kroku wiele zależy od tego jak stworzona została aplikacja i z czego korzysta więc zbyt wiele nie potrafie opisać.
Ważna uwaga dotycząca biezpieczeństwa. Standardowo DreamHost zakłada katalogi z prawami do odczytu i uruchamiania dla wszystkich (755) - przez co jeżeli ktoś zna ścieżkę, może dodać sobie nasz katalog z projektami i działać na modułach. Jeżeli chcemy by to nie było możliwe możemy zmienić prawa dostępu tak. (Jeżeli przez to pojawią się problemy robimy: chmod 755 -R ~/django_projects/ po czym chmod 600 ~/django_projects/djangopl/settings.py):
-
chmod 700 -R ~/django_projects/
-
chmod 600 ~/django_projects/djangopl/settings.py
-
vim ~/django_projects/djangopl/settings.py
Krótki tutorial dotyczący Vima.
W skrócie: aby wprowadzać tekst wciskamy: insert (lub i) aby zapisać zmiany Esc (jeżeli jesteśmy w trybie wprowadzania) później :x. Aby skasować całą linię: Esc (jeżeli jesteśmy w trybie wprowadzania tekstu) i dd.
Teraz możemy sprawić by nasz projekt (tu djangopl) był serwowany pod domena sandpit.django.pl:
-
cd ~/sandpit.django.pl/
-
vim dispatch.fcgi
Do pliku wklejamy ten kod uwzględniając oczywiście zmianę katalogu użytkownika (tu sandpit_djangopl) :
-
#!/usr/bin/env python2.4
-
ROOT = "/home/sandpit_djangopl/"
-
import sys, os
-
sys.path += [ROOT + "flup_src"]
-
sys.path += [ROOT + "django_src"]
-
sys.path += [ROOT + "django_projects"]
-
os.environ["DJANGO_SETTINGS_MODULE"] = "djangopl.settings"
-
from django.core.servers.fastcgi import runfastcgi
-
runfastcgi(method="threaded", daemonize="false")
Zamykamy plik i w konsoli zmieniamy jego prawa:
-
chmod 755 dispatch.fcgi
Sprawmy by Apache wszystko poza odwołaniami do zawartości katalogów media i admin_media oddelegowywał przez dispatch.fcgi do Django. Plik .htaccess musi znajdować sie w katalogu głównym naszej domeny:
-
vim .htaccess
-
AddHandler fastcgi-script .fcgi
-
RewriteEngine On
-
RewriteBase /
-
RewriteRule ^(media/.*)$ - [L]
-
RewriteRule ^(admin_media/.*)$ - [L]
-
RewriteRule ^(dispatch\.fcgi/.*)$ - [L]
-
RewriteRule ^(.*)$ dispatch.fcgi/$1 [L]
Katalogi admin i admin_media zlinkujemy do odpowiednich scieżek skonfigurowanych w settings.py:
-
ln -s ~/django_projects/djangopl/media ~/sandpit.django.pl/media
-
ln -s ~/django_src/django/contrib/admin/media/ ~/sandpit.django.pl/admin_media
Teoretycznie nasz projekt jest już wystawiony i powinien działać. Wchodzimy tu: http://sandpit.django.pl.
Ewentualne Problemy.
Pamiętajmy o tym, że domena potrzebuje trochę czasu na propagację. Dodatkowo nie wiem dlaczego ale często byba, że Apache na DreamHoście zaczyna odpalać skrypty FastCGI dopiero po pewnym czasie. Przy pierwszych walkach okazywało się, że po godzinach spędzonych nad uruchomieniem - następnego dnia wszystko działało bez zarzutu.
Możliwe jest, że aplikacja wyrzuca wyjątek i jeżeli ustawiny mamy DEBUG=False (a tak powinniśmy zrobić) możemy sprawdzić sam skrypt tak:
-
REQUEST_METHOD="GET" REQUEST_URI="/" QUERY_STRING="" SERVER_NAME="sandpit.django.pl" SERVER_PORT="80" SERVER_PROTOCOL="HTTP" PATH_INFO="/" ./dispatch.fcgi | grep Status
Skrypt ten przeszukuje linii kody, która zawiera słowo Status. Jeżeli pojawi się:
-
Status: 200 OK
będzie to oznaczało, że wszystko gra. Jeżeli pominiemy fragment | grep Status skrypt powinien w konsoli “wypluć” czysty zwrot (np HTML)
PS właśnie dostałem zwrot od Supportu DreamHosta i może uda mi się podać receptę na instalacje Django i Pylons z użyciem Virtual Pythona.
Jeżeli cokolwiek jest niejasne bądź okaże się, że popełniłem gdzieś błąd - proszę komentujcie, razem ulepszymy ten poradnik.



12. June, 2007 at 23:30
Jest błąd w kodzie .htaccess:
Jest linia:
#
RewriteRule ^(dispatch.fcgi/.*)$ - [L]
A powinna być:
#
RewriteRule ^(dispatch\.fcgi/.*)$ - [L]
13. June, 2007 at 02:17
Masz rację, już poprawiłem. Dzięki za czujność.
29. July, 2007 at 01:37
Fajnie ze chcialo Ci sie zlozyc tego tutka :) U mnie instalacja poszla bezproblemowo.
Jednak zaraz po postawieniu django na DH zaczely sie inne problemy. Co moze byc przyczyna ze projekt po wprowadzeniu zmian np do views.py nie odswieza sie ? Czasem trzeba czekac 10 minut - czasem godzine, nie musze mowic jak to jest irytujace …
Podejrzewam ze ma to zwiazazek z djangowym systemem cache. Nie wprowadzam zmian do modelu, wiec chyba syncdb nie trzeba odpalac po kazdej zmianie w projekcie ?
29. July, 2007 at 02:21
Zainstalowałem Django zgodnie z tutorialem na dreamhoście i po wejściu na stronę mam cały czas biały ekran, niby coś się ładuję ale można czekać i czekać. Czym to może być spowodowane?
29. July, 2007 at 05:25
Pawel: U mnie na poczatku bylo podobnie, po paru godzinach samo zaczelo dzialac. hm
29. July, 2007 at 07:25
Tylko że zainstalowałem to jakiś tydzień temu, dzisiaj spróbowałem jeszcze raz i nadal to samo. W error.log dla domeny mam:
Sun Jul 29 05:18:07 2007] [error] [client 83.***] FastCGI: comm with (dynamic) server “/home/user/django.domena.pl/dispatch.fcgi” aborted: (first read) idle timeout (60 sec)
[Sun Jul 29 05:18:07 2007] [error] [client 83.*** FastCGI: incomplete headers (0 bytes) received from server “/home/user/django.domena.pl/dispatch.fcgi”
29. July, 2007 at 14:59
@Pawel
Milem dokladnie to samo, sprawdz czy na pewno masz dobre sciezki w plikach i sprawdz uprawnienia.
@makyo
Nie wiem dlaczego tak sie dzieje ale u mnie tez tak bywalo i nie ma to nic wspolnego z Django (mialem to tez na Pylons) nie wiem dlaczego tak jest.
30. July, 2007 at 03:09
Ścieżki sprawdzałem dwukrotnie, chmody też są w porządku. Wydaje mi się że to jest ze ścieżką do pythona. Na blogu Jeffa ktoś w komentarzach miał podobny problem (nie rozwiązany). Gdy próbuje wpisać source dispatch.fcgi to pojawia mi się:
[fairlane]$ source dispatch.fcgi
import: unable to open X server `’.
-bash: sys.path: command not found
-bash: sys.path: command not found
from: can’t read /var/mail/fcgi
from: can’t read /var/mail/django.core.handlers.wsgi
import: unable to open X server `’.
-bash: os.environ[DJANGO_SETTINGS_MODULE]: command not found
-bash: dispatch.fcgi: line 9: syntax error near unexpected token `WSGIHandler’
‘bash: dispatch.fcgi: line 9: `WSGIServer(WSGIHandler()).run()
Mój plik dispatch.fcgi wygląda tak:
#!/usr/bin/env python
import sys
sys.path += [’/home/user/django/django_src’]
sys.path += [’/home/user/django/django_projects’]
from fcgi import WSGIServer
from django.core.handlers.wsgi import WSGIHandler
import os
os.environ[’DJANGO_SETTINGS_MODULE’] = ‘projekt.settings’
WSGIServer(WSGIHandler()).run()
30. July, 2007 at 03:39
sys.path += [’/home/user/django/django_src’]
sys.path += [’/home/user/django/django_projects’]
A to jest na 100% dobrze w Twoim przypadku?
masz uzytkownika, ktory nazywa sie “user”?
Pewnie tez lepiej zmienic to:
#!/usr/bin/env python
na to:
#!/usr/bin/env python2.4
30. July, 2007 at 03:45
Nie mam “user” ;). Po prostu nie czuje potrzeby podawania wszystkim nazwy użytkownika. Po zmianie na “#!/usr/bin/env python2.4″ cały czas wyskakuje ten sam error, a strona nie działa.
30. July, 2007 at 04:09
Wybacz, widzialem rozne bledy w zyciu :)
Nie mam pojecia co to moze byc. Stawialbym na uprawnienia ale skoro sprawdziles. Milem to samo i nie pamietam jak to rozwiazalem wtedy.