onjin.net » home.pl & django – pierwsza potyczka

home.pl & django – pierwsza potyczka

home.pl obsługuje pythona jako cgi (pliki .py) więc tego będziemy się trzymać. Instalację wykonamy w katalogu /py

instalacja django

hardcoded ale działa wrzucamy to do /py i ruchamiamy poprzez www

cat install.py
#!/usr/bin/env python
import os

os.system("wget http://www.djangoproject.com/download/1.0.2/tarball/")
os.system("tar zxf Django-1.0.2-final.tar.gz")
os.system("rm Django-1.0.2-final.tar.gz")
os.system("mv Django-1.0.2-final tmp")
os.system("mv tmp/django django")

nasz projekt

Lokalnie wołamy

django-admin.py startproject pytest

i wrzucamy katalog pytest przez ftp na home do katalogu /py .

dispatcher.py

cat dispatch.py
#!/usr/bin/env python

import os, sys
import django.core.handlers.wsgi

def run_with_cgi(application):

    environ                      = dict(os.environ.items())
    environ['wsgi.input']        = sys.stdin
    environ['wsgi.errors']       = sys.stderr
    environ['wsgi.version']      = (1,0)
    environ['wsgi.multithread']  = False
    environ['wsgi.multiprocess'] = True
    environ['wsgi.run_once']     = True

    if environ.get('HTTPS','off') in ('on','1'):
        environ['wsgi.url_scheme'] = 'https'
    else:
        environ['wsgi.url_scheme'] = 'http'

    headers_set  = []
    headers_sent = []

    def write(data):
        if not headers_set:
             raise AssertionError("write() before start_response()")

        elif not headers_sent:
             # Before the first output, send the stored headers
             status, response_headers = headers_sent[:] = headers_set
             sys.stdout.write('Status: %s\\r\\n' % status)
             for header in response_headers:
                 sys.stdout.write('%s: %s\\r\\n' % header)
             sys.stdout.write('\\r\\n')

        sys.stdout.write(data)
        sys.stdout.flush()

    def start_response(status,response_headers,exc_info=None):
        if exc_info:
            try:
                if headers_sent:
                    # Re-raise original exception if headers sent
                    raise exc_info[0], exc_info[1], exc_info[2]
            finally:
                exc_info = None     # avoid dangling circular ref
        elif headers_set:
            raise AssertionError("Headers already set!")

        headers_set[:] = [status,response_headers]
        return write

    result = application(environ, start_response)
    try:
        for data in result:
            if data:    # don't send headers until body appears
                write(data)
        if not headers_sent:
            write('')   # send headers now if body was empty
    finally:
        if hasattr(result,'close'):
            result.close()

# Change this to the directory above your site code.
sys.path.append("/py")
# Change mysite to the name of your site package
os.environ['DJANGO_SETTINGS_MODULE'] = 'pytest.settings'

run_with_cgi(django.core.handlers.wsgi.WSGIHandler())

i odpalamy to by www na razie tyle …

Dokładam paczkę z plikami do testu:

py.zip

unzip py.zip; ftp na home.pl; open http://server.home.pl/py/dispatch.py/admin

Share and Enjoy:

22 Comments to “home.pl & django – pierwsza potyczka”

mbw 27 marca 2009 at 23:23 #

Ciekawy wpis. Mam pytanie: udało Ci się skonfigurować następnie w Django dostęp do bazy danych? Mi cały czas rzuca błędami (mysql): nie może wywołać pwd.getpwuid(os.getuid()) – odrzuca uid.
Marek 28 marca 2009 at 17:48 #

Na razie uruchomiłem na sqlite, z mysq/postgres jeszcze niepróbowałem. Ale w najbliższych dniach będę próbował to dam znać
Szymon 21 czerwca 2009 at 11:00 #

Czy jeszcze jakies pliki sa potrzebne aby uruchomic na home.pl? Mnie sie niestety nie udalo Masz moze jakas gotowa przykladowa paczke dla testow? Z gory dzieki.
Marek 21 czerwca 2009 at 17:45 #

Mam paczkę, którą wykonywałem test:
* http://onjin.net/files/py.zip

wrzucić na server, rozpakować i powinno zadziałać:
* http://server.home.pl/py/dispatch.cgi/admin
eXpose 2 października 2009 at 13:57 #

Prawie mi się udało tzn. działa obsługa sql tylko nie moge odpalić panelu admina. Może komuś się udało?
Marek 2 października 2009 at 14:00 #

Panel działa bez problemu. Jakie są objawy/komunikaty w Twoim przypadku?
eXpose 3 października 2009 at 08:30 #

Dostaje cały czas błąd 404. Używam django 1.1 i do pliku dispatch.py dodałem os.environ['HOME']=’/’ żeby używać mysql
Marek 4 października 2009 at 01:35 #

Spróbuj bez dodawania ‘HOME’. Paczkę do mysql’a wystarczy, że wgrasz na ścieżkę, dostępną z projektu.
czemiello 6 listopada 2009 at 01:14 #

Hej a wiesz moze jak poradzic sobie z bugiem takim ze nie akceptuje ciasteczek na serwerze home.pl
http://code.djangoproject.com/ticket/4220
tutaj link do buga
robb 2 stycznia 2010 at 10:34 #

A czy nie jest tak, że korzystając z modelu cgi tracimy najlepsze co daje django, czyli szybkość? Czy nie jest tak, że z każdym requestem cały framework przeżywa cold start?
Niech mnie ktoś poprawi jeśli się mylę.
Marek 2 stycznia 2010 at 12:19 #

Tak, przy cgi aplikacja musi wstawać za każdym razem. W przypadku home.pl nie ma innej możliwości. Czy będzie to python, perl czy php aplikacja i tak jak żołnierz, padnij powstań robi . Pozostaje więc tylko wybór ulubionego języka do pracy.
Uruchamianie projektu Django na home.pl « IT Guy VS World

[...] którzy mają problemy z uruchomieniem aplikacji django na serwerach home.pl polecam ten wpis. Tagi: django, Programming Podziel [...]
Pawel 2 marca 2010 at 13:46 #

Dzięki wielkie za ten poradnik. Natrafiłem na taki problem. .htaccess wskazuje na dispatch.py oraz ustawiłem subdomenę na katalog py/. I teraz jeżeli staram się wskazać jakikolwiek widok muszę to robić przez loginhome.home.pl/py/dispatch.py/widok jednakże nie jestem w stanie uzyskać tego wyniku przez zastosowanie subdomeny (czyli subdomena/widok). Jakaś wskazówka gdzie mogę znależć rozwiązanie?
Marek 2 marca 2010 at 14:10 #

W pliku ‘dispatch.py’ znajduje się linijka ‘sys.path.append(„/py”)’ i to jest problem.

Jak wchodzisz przez domenę trzeba by zamiast /py dać /, lub prościej: ‘sys.path.append( os.path.join(os.path.dirname(__file__) )’
Pawel 2 marca 2010 at 15:30 #

Dzięki za odpowiedź. Niestety nadal coś chrzanię
w urls.py mam takie wpisy:
(‘^$’, root_site),
(‘^test/$’, podstrona),

Zarówno ‘root_site’ jak i ‘podstrona’ wyrzucają tekst za pośrednictwem HttpResponse. ‘root_site’ łąduje się bez problemu (zarówno przez domenę jak i przez bezpośrednie odwołanie) natomiast ‘podstrona’ zostanie wyświetlona tylko przez bezpośrednie wywołanie dispatch.py.
Spróbowałem obydwu zaproponowanych przez Ciebie zmian i zero efektu.

P.S.
Sam „program” (chociaż ja bym tego tak dumnie nie nazwał) testowałem lokalnie oraz na testowym koncie na megiteam.pl – i działa
Marek 4 marca 2010 at 09:13 #

Nie jestem pewien, ale może zamień kolejność w urls.py, umieszczając ^$ na końcu
wojtas 5 maja 2010 at 00:27 #

trzeba miec serwer dedykowany u nich by odpalic django? Czy moze byc np „Hosting UNIX” ?
Marek 5 maja 2010 at 07:07 #

Ten przykład odpaliłem na zwykłym hostingu, bez dedyka. W przypadku dedyka możesz użyć fcgi lub wsgi i wszystko będzie chodzić o wiele szybciej.
YatZeck 11 maja 2010 at 18:28 #

Potiwerdzam – da się uruchomić to na „zwyczajnym” hostingu. Chciałbym się tylko zmienić 1 szczegół. Obecnie adres wygląda tak http://ladny-adres/py/dispatch.py/admin i nie hest to ladny adres. Miło by było, aby strona dostępna była jako http://ladny-adres/py/admin.
Da radę?
Marek 11 maja 2010 at 19:01 #

w .htaccess wpisujemy:

DirectoryIndex dispatch.py
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /dispatch.py/$1 [L]
YatZeck 11 maja 2010 at 19:16 #

Thx! Ciągle o tym zapominam – cóż nie jeste ze mnie dziecko www:)
Marek 11 maja 2010 at 19:53 #

np. powodzenia z projektem